jdk jre jvm 的區別和聯系，java client和servers_“java -server”和“java -client”之間的真正區別？

這實際上與HotSpot和默認選項值 ( Java HotSpot VM選項 )相關聯，這些選項在客戶端和服務器configuration之間有所不同。

從白皮書( The Java HotSpot Performance Engine Architecture )的第2章開始 ：

JDK包含兩種types的VM – 客戶端產品和針對服務器應用程序調優的VM。 這兩個解決scheme共享Java HotSpot運行時環境代碼庫，但使用不同的編譯器，這些編譯器適合于客戶端和服務器的獨特性能特征。 這些差異包括編譯內聯策略和堆默認值。

jdk jre jvm 的區別和聯系、盡pipe服務器和客戶端虛擬機類似，但是服務器虛擬機已經過特殊調整，以最大化運行速度。 它旨在執行長時間運行的服務器應用程序，這些應用程序需要最快的運行速度，而不是快速啟動時間或更小的運行時內存占用量。

客戶端VM編譯器可用作舊版本JDK所使用的Classic VM和實時(JIT)編譯器的升級。 客戶端VM為應用程序和小應用程序提供改進的運行時間性能。 Java HotSpot客戶端虛擬機經過特別調整，可以減less應用程序的啟動時間和內存占用，使其特別適合于客戶端環境。 一般來說，客戶端系統對GUI更好。

所以真正的區別也在編譯器級別上：

客戶端VM編譯器不會嘗試在服務器虛擬機中執行許多由編譯器執行的更復雜的優化，但作為交換，它需要更less的時間來分析和編譯一段代碼。 這意味著客戶端虛擬機可以更快地啟動，并且需要更小的內存占用量。

jdk jre jvm之間有什么關系、Server VM包含一個高級自適應編譯器，支持通過優化C ++編譯器執行的許多相同types的優化，以及傳統編譯器無法完成的一些優化，例如跨虛擬方法調用的積極內聯。 與靜態編譯器相比，這是一個有競爭力的性能優勢。 自適應優化技術在其方法中是非常靈活的，并且典型地甚至比先進的靜態分析和編譯技術更勝一籌。

注： jdk6更新10 (請參閱更新發行說明：1.6.0_10中的更改 )的發布嘗試提高啟動時間，但是由于與熱點選項不同的原因，打包方式與更小的內核不同。

G. Demecki 在評論中指出，在64位版本的JDK中， -client選項被忽略了很多年。

看到Windows的java命令 ：

java中client。-client

selectJava HotSpot客戶端VM。

目前支持64位的JDK忽略此選項，而是使用Java Hotspot Server VM 。

舊版Java中最明顯的即時差異是分配給-client的內存，而不是-server應用程序。 例如，在我的Linux系統上，我得到：

server。$ java -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E 'heapsize|permsize|version' uintx AdaptivePermSizeWeight = 20 {product} uintx ErgoHeapSizeLimit = 0 {product} uintx InitialHeapSize := 66328448 {product} uintx LargePageHeapSizeThreshold = 134217728 {product} uintx MaxHeapSize := 1063256064 {product} uintx MaxPermSize = 67108864 {pd product} uintx PermSize = 16777216 {pd product} java version "1.6.0_24"

因為它默認為-server ，但是使用-client選項：

$ java -client -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E 'heapsize|permsize|version' uintx AdaptivePermSizeWeight = 20 {product} uintx ErgoHeapSizeLimit = 0 {product} uintx InitialHeapSize := 16777216 {product} uintx LargePageHeapSizeThreshold = 134217728 {product} uintx MaxHeapSize := 268435456 {product} uintx MaxPermSize = 67108864 {pd product} uintx PermSize = 12582912 {pd product} java version "1.6.0_24"

所以對于這個java版本，大部分內存限制和初始分配都要高得多。

java。但是，這些值可能會改變體系結構，操作系統和jvm版本的不同組合。 jvm的最新版本已經刪除了標志并重新移動了服務器和客戶端之間的許多區別。

請記住，您可以使用jvisualvm查看正在運行的jvm所有細節。 如果您擁有設置JAVA_OPTS用戶或模塊??，或使用更改命令行選項的腳本，則此function非常有用。 這也可以讓你實時監控堆和空間的使用情況以及其他很多的統計數據。

我剛剛注意到的一個區別是，在“客戶端”模式下，JVM實際上將一些未使用的內存提供給操作系統 – 而在“服務器”模式下，一旦JVM抓取內存，它就不會給它背部。 這就是它在Solaris上如何使用Java6(使用prstat -Z來查看分配給進程的內存量)。

Oracle的在線文檔為Java SE 7提供了一些信息。

java調用httpclient？在java -用于Windows 的Java應用程序啟動程序頁面上，在64位JDK中忽略-client選項：

selectJava HotSpot客戶端VM。 一個支持64位的jdk目前忽略這個選項，而是使用Java HotSpot Server VM。

然而(為了使事情有趣)，在服務器下面說：

selectJava HotSpot Server VM。 在支持64位的jdk上，只支持Java HotSpot Server虛擬機，所以-server選項是隱含的。 這將在未來的版本中發生變化。

java的client包，“ 服務器級機器檢測”頁面提供有關按操作系統和體系結構select哪個VM的信息。

我不知道這適用于JDK 6有多less。

-client和-server系統是不同的二進制文件。 它們本質上是兩個不同的編譯器(JIT)，連接到相同的運行時系統。 客戶端系統適用于需要快速啟動時間或占用空間小的應用程序，服務器系統最適合整體性能最為重要的應用程序。 一般來說，客戶端系統更適合GUI等交互式應用程序

我們用兩個開關運行下面的代碼：

client java？package com.blogspot.sdoulger; public class LoopTest { public LoopTest() { super(); } public static void main(String[] args) { long start = System.currentTimeMillis(); spendTime(); long end = System.currentTimeMillis(); System.out.println("Time spent: "+ (end-start)); LoopTest loopTest = new LoopTest(); } private static void spendTime() { for (int i =500000000;i>0;i--) { } } }

注意：代碼只被編譯一次！ 這兩個class的class都是一樣的！

用-client：

java.exe -client -classpath C：\ mywork \ classes com.blogspot.sdoulger.LoopTest

java.net.socket。花費的時間：766

用-server：

java.exe -server -classpath C：\ mywork \ classes com.blogspot.sdoulger.LoopTest

花費的時間：0

看來服務器系統更積極的優化，刪除循環，因為它明白，它不會執行任何操作！

參考

IIRC服務器虛擬機在啟動時做了更多的熱點優化，所以運行速度更快，但需要更長的時間才能啟動并使用更多的內存。 客戶端VM推遲大部分優化以允許更快的啟動。

編輯添加： 這是從Sun 的一些信息 ，這不是很具體，但會給你一些想法。

從Goetz – Java并發實踐：

debugging提示：對于服務器應用程序，確保在調用JVM時始終指定-server JVM命令行開關， 即使對于開發和testing也是如此 。 服務器JVM執行比客戶端JVM更多的優化，例如將循環中沒有修改的variables提取出來; 可能在開發環境(客戶端JVM)中工作的代碼可能會在部署環境(服務器JVM)中崩潰。 例如，如果我們忘記在清單3.4中聲明variablesasleep為volatile， 那么服務器JVM可以將testing從循環中提取出來(將其變成無限循環)，但是客戶機JVM不會 。 在開發過程中出現的無限循環比僅在生產中出現的成本要低得多。

代碼3.4 數羊。

volatile boolean asleep; ... while (!asleep) countSomeSheep();

我的重點。 因人而異

IIRC，它涉及垃圾收集策略。 理論上，客戶端和服務器在短期對象方面是不同的，這對于現代的GCalgorithm是重要的。

這是服務器模式的鏈接 。 唉，他們不提客戶端模式。

總的來說， 這是一個非常透徹的 GC的鏈接 。 這是一個更基礎的文章 。 不知道，如果任何地址的服務器VS客戶端，但這是相關的材料。

在沒有絨毛的事情上，肯·斯佩和格倫·范登堡都在做這樣的事情。

我沒有注意到2之間的啟動時間有任何差異，但是通過“-server”(Solaris服務器，每個使用SunRays來運行應用程序)的應用程序性能都有一個非常小的改進。 那是在1.5以下。

上次我看了一下這個(不可否認的是，有一段時間了)，我注意到的最大的區別是垃圾回收。

IIRC：

服務器堆虛擬機具有與客戶機虛擬機不同的世代，并且具有不同的垃圾收集algorithm。 這可能不是真的了

服務器虛擬機將分配內存，而不是釋放到操作系統

服務器虛擬機將使用更復雜的優化algorithm，因此對優化有更大的時間和內存要求

如果您可以比較兩個Java虛擬機，一個客戶端，一個使用jvisualvm工具的服務器，則應該看到垃圾收集的頻率和效果以及代數的差異。

我有一對截圖，顯示差異非常好，但我不能重現，因為我有一個64位的JVM，只實現服務器虛擬機。 (而且我也不能打擾在我的系統上下載和爭奪32位版本。)

這似乎不是這種情況了，試圖在服務器和客戶端虛擬機上運行一些代碼在Windows上，我似乎得到了同樣的代模型…

當從1.4遷移到1.7(“1.7.0_55”)版本時，我們在這里觀察到的情況是，在客戶端和服務器模式下，默認值分配給hemsize | permsize | ThreadStackSize參數沒有這種差異。

initial heap size of 1/64 of physical memory up to 1Gbyte maximum heap size of ? of physical memory up to 1Gbyte

ThreadStackSize在1.7中更高，在經過Open JDK論壇的時候，在1.7版本中有討論說幀大小有點高。 據信，根據您的應用程序的行為，可以在運行時測量真正的差異