Java HotSpotTM VM 簡介
寫在前面
JavaTM 技術已經逐漸變程式軟體程式開發的主流了，隨著各界對於 Java 的採納，這項技術在各個領域都是以爆炸性的速度在成長，不管是從信用卡到大型主機上，或是從網頁上的 applet 到大型的商業應用技術。在過去，雖然 JavaTM 技術提供了一個不但容易移植，而且又安全的開發環境，但也由於容易移植的這個特性，造成了程式在執行的時候效能的低落。不過目前的技術發展進步，所以在效能上的低落這項缺點，也逐漸的改進了。
Java HotSpotTM 虛擬機器（VM）是 Java 2 Platform, Standard Edition（J2SETM）軟體的一項核心技術，並且廣泛的被一些「整合開發環境（IDEs）」還有「Application Server」所使用，包括有 ForteTM for JavaTM、Borland JBuilder、WebGain VisualCafe、Oracle JDeveloper、MetrowerksCodeWarrior、NetBeansTM Open SourceProject、BEA Systems（WebLogic Server）還有 iPlanet（iPlanetTM Application Server）等等。與之前的版本比較起來，Java HotSpotTM 虛擬機器在效能方面加強了許多，特別是在 garbage collection 還有 thread 的處理方面。此外，Java HotSpotTM 虛擬機器可以透過「client」或是「server」這兩個字來決定是要使用 Java HotSpot Client VM 或是 Java HotSpot Server VM 來將應用程式作最佳效能的處理。
在 Java 2 SDK, Standard Edition v1.3.1當中，Java HotSpot VM 包含了許許多多新的效能提升技術，最主要增加的地方有以下幾點：
1.在執行時間（Runtime）方面
§當致命的錯誤在虛擬機器當中發生，不論是在 VM 當中引起的，或是由使用者使用的 native code，都會有較佳的回報功能。
§Java VirtualMachine Debugger Interface（JVMDI）和 Java Virtual Machine Profiler Interface（JVMPT）的特性現在完全支援了。
§在這個版本的 VM 是由一致性的原始碼所建構出來的，方便移植到所有支援的平台。
2.在 GarbageCollection 方面
§Garbage collector 現在已經可以完全使用 32-bit 系統中的位址空間了，這表示可以存取 4g 大小的 heap 了。不過在這邊要注意的是，並不是所有的作業環境都支援這麼大的 heap，SolarisTM 的話有支援。
§Garbage collector 已經調整用來支援大型應用程式和 UltraSPARCTM III 平台。
3.在 JavaHotSpot Client VM 方面
§確保 VM 的特性可以橫跨所支援的平台。
4.在 JavaHotSpot Server VM 最佳化方面
§Java 在對於每個陣列的存取，都會去檢查有無超過邊界。但若是編譯器已經確定陣列存取是在範圍之內的話，那麼就可以把這項檢查消除掉。
§Server VM 現在新增加了 loop unrolling 這項特性，可以用來加快迴圈的執行。
§對於 UltraSPARCIII 的最佳化增加了 instruction scheduling 的功能。
§對 Javareflection API 做物件導向的最佳化處理。
Java HotSpot VM 的架構
對於 Java HotSpot VM 它的架構，在這邊我們分成下面幾個方向來介紹說明：
1.記憶體模型（memorymodel）方面
在 以往先前的 Java 虛擬機器當中，是使用間接處理的方式來處理物件之間的參考。這使的我們在 garbage collection 的時候要 relocate 物件會變的比較容易，不過，這卻也變成是效能的瓶頸所在。因為當我們要存取所實作出來物件當中的變數的話，要經過兩層的步驟。
新 一代的 Java HotSpot VM 對於物件之間的參考，就直接實作成了指標，所以我們可以就像是用 C 的存取速度來存取我們實作出來的變數。而 garbage collector 就是當物件在記憶體當中被 relocate 的時候，我們為了要找出或是更新在同一塊區域當中，所有同樣參考到這個物件所設計出來的。
除此之外，新的 Java HotSpot VM 也使用了有兩個機器字元的檔頭（machine-word object header）來取代之前所採用的三個，這表示我們對於每個應用程式可以節省掉將進 8% 的 heap大小。在這邊，第一個header 包含了例如 hash code 或是garbage collector 狀態的訊息，第二個 header 則是表示參考到哪個物件類別，只有當我們使用陣列的時候才會出現第三個 header 欄位－是用來表示陣列大小的。
2.Garbage Collection方面
對 於程式設計者來說，使用 Java 作為其程式開發語言其中有個重要的因素是，它提供了自動的記憶體管理（或稱之為 garbage collection）。在傳統的程式語言上，我們要動態的配置記憶體空間的話，需要由我們自己設定。但在實際上，這也容易造成程式經常記憶體使用不足，或是易造成 crash。
當新一代的 garbage collector 在確定並且證明某個物件已經不會在這個程式當中被使用到了，那麼，它會在背景自動處理釋放這些已經沒有在使用的物件所佔的記憶體。
在傳統上，garbage collection 經常會帶給大家這是個沒有效率的處理，或是程式效能低落的瓶頸所在。但是在新一代的 garbage collection 技術當中，會自動的考慮到整體的效能，並且對於記憶體釋放有更好的處理。
3.ThreadSynchronization 方面
在 過去 Java 在同步化的實作上，會相當的沒有效率是因為跟其他在 Java 當中的操作運算有關，同時也是效能的瓶頸所在的主要原因之一。新一代的 JavaHotSpot VM 在 thread 的實作上面有重大的突破，包含提高同步效能這個項目。此外，Java HotSpot VM 對於 thread 處理提供了線性執行還有有加速的能力，並且設計能夠在擁有大量共享記憶體的多處理器伺服器上能夠立刻變化擴充加速處理的能力。
上次小弟為大家簡單介紹了 Java 2 SDK, Standard Edition v1.3.1當中，Java HotSpot VM 的一些新的特性和它的架構，這次小弟將跟大家繼續介紹 Java HotSpot VM 和其編譯器（compiler）部份。
相 信在大家安裝完 Java 2 SDK, Standard Edition v1.3.1之後，若您的作業系統是 Windows 的話，會在 C:/安裝 jdk 的目錄/jre/bin 下發現有三個目錄，分別為「classic」、「hotspot」和「server」這三個。若是您在提示符號下執行 java.exe 程式的話，後面接上 -version 的參數，則可分別看到類似下面的訊息：
C:/jdk/jre/bin>java -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
C:/jdk/jre/bin>
C:/jdk/jre/bin>java -server -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Server VM (build 1.3.1-b24, mixed mode)
C:/jdk/jre/bin>
C:/jdk/jre/bin>java -classic -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Classic VM (build 1.3.1-b24, native threads, nojit)
C:/jdk/jre/bin>
另外，若是使用 -X 的參數的話，也可以看到明顯的不同：
C:/>java -server -X -Xmixed mixed mode execution (default) -Xint interpreted mode execution only -Xbootclasspath:<directories and zip/jar files separated by ;> set search path for bootstrap classes and resources -Xbootclasspath/a:<directories and zip/jar files separated by ;> append to end of bootstrap class path -Xbootclasspath/p:<directories and zip/jar files separated by ;> prepend in front of bootstrap class path -Xnoclassgc disable class garbage collection -Xincgc enable incremental garbage collection -Xbatch disable background compilation -Xms<size> set initial Java heap size -Xmx<size> set maximum Java heap size -Xss<size> set java thread stack size -Xprof output cpu profiling data -Xrunhprof[:help]|[:<option>=<value>, …] perform JVMPI heap, cpu, or monitor profiling -Xdebug enable remote debugging -Xfuture enable strictest checks, anticipating future default -Xrs reduce use of OS signals by Java/VM (see documentation) The -X options are non-standard and subject to change without notice.
C:/>
C:/>java -classic -X -Xbootclasspath:<directories and zip/jar files separated by ;> set search path for bootstrap classes and resources -Xbootclasspath/a:<directories and zip/jar files separated by ;> append to end of bootstrap class path -Xbootclasspath/p:<directories and zip/jar files separated by ;> prepend in front of bootstrap class path -Xnoclassgc disable class garbage collection -Xms<size> set initial Java heap size -Xmx<size> set maximum Java heap size -Xrs reduce the use of OS signals -Xcheck:jni perform additional checks for JNI functions -Xcheck:nabounds perform additional checks for JNI array operations -Xrunhprof[:help]|[:<option>=<value>, …] perform heap, cpu, or monitor profiling -Xdebug enable remote debugging -Xfuture enable strictest checks, anticipating future default The -X options are non-standard and subject to change without notice.
C:>
從 上面的訊息我們可以看到，除了傳統的 Classic VM 之外，Java HotSpot VM 還分成了 Client VM 和 Server VM。其實，不管是 client 還是 server 的VM，都共用了 Java HotSpot 執行環境的基本程式，但是它們使用了不同的編譯器來讓 client 或是 server 端執行環境的效能特性能夠彰顯出來。對於 server VM 來說，它會特別將程式的操作速度微調至最好的部份，所以用來執行server 端的應用程式的話，可以擁有較快的啟動時間還有當應用程式在執行的時候，會佔據較少的記憶體空間。另外，對於 client VM 來說，它主要增進的效能是在於 client 端的應用程式，或是 applet 部份。Java HotSpot Client VM 會特別調整應用程式的啟動速度和記憶體使用空間，讓它對於我們在 client 的環境可以「非常速配」。一班來說，若是 client 端系統有 GUI 介面的話，會有比較好的成效。
在編譯器方面的話，client VM 的編譯器並不會去執行類似像是 server VM 那樣複雜的最佳化技術，所以它會花較少的時間在分析和編譯 code 上面。從另一個觀點來看，就是它在啟動時間會增快，並且耗費較少的記憶體空間。另外，client VM 在編譯的過程可以分為兩個階段來描述，第一個部份是各平台獨立的分析bytecode，第二部份的話，則是根據各個平台不同來產生機器碼。相對的在 server VM 方面，它使用了更強的「具有可調變能力的編譯器」，這比傳統的靜態的編譯器具有更多的優點與特性。
結語
Java HotSpot VM 在程式方面做了更強的最佳化處理，另外，在 garbage collection 還有 thread 同步方面也做了相當大的改進。除此之外，Java HotSpot VM 對於 client 和 server 端的應用程式，分別提供了不同的執行環境，使的應用程式在執行的時候，可以獲得最好的效果。若是大家對於 Java HotSpot VM 有興趣的話，可以到 http://java.sun.com/products/hotspot/index.html這邊獲得更多的相關資料。
看看你下面的这两个文件，是不是尺寸差别很大？ %JAVA_HOME%/jre/bin/client/jvm.dll %JAVA_HOME%/jre/bin/server/jvm.dll Jvm动态库有client和server两个版本，分别针对桌面应用和服务器应用做了相应的优化，client版本加 载速度较快，server版本加载速度较慢但运行起来较快。 让Tomcat 使用Server版本的jvm吧 在开始菜单 tomcat5 ->tomcat config的java属性中 有一项 jvm路径 指向server目录下的jvm就行了。 启动速度对比一下，在我的C4.17512M 的机器上client 版本一般在8s-16s内启动完成 server版本 在21s-26s左右启动完成。 更改默认java.exe调用的jvm.dll,这个由jvm.cfg决定。 编辑%JAVA_HOME%/jre/lib/i386/jvm.cfg里面第一行写的是-client 默认就是client版本 ，把第二行的-server KNOWN 放到第一行， 如下面所示 -server KNOWN -client KNOWN -hotspot ALIASED_TO -client -classic WARN -native ERROR -green ERROR 改完保存，然后看看默认版本： C:/java -version java version "1.4.2_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05) Java HotSpot(TM) Server VM (build 1.4.2_07-b05, mixed mode) 看到没有 Server VM字样？是不是很酷啊！，小心机器不够快，启动等得你疯掉 ：）
无论如何，没有人有办法把自己抑或他人的刺拔掉。那是一碰便痛的软肋，
