“java -server”和“java -client”之间的真正区别？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/198577/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Real differences between "java -server" and "java -client"?
提问by Paul Tomblin
Is there any real practical difference between "java -server" and "java -client"?
“java -server”和“java -client”之间有什么真正的实际区别吗？
All I can find on Sun's site is a vague
我在 Sun 的网站上只能找到一个模糊的信息
"-server starts slower but should run faster".
“-server 启动较慢，但应该运行得更快”。
What are the real differences? (Using JDK 1.6.0_07 currently.)
真正的区别是什么？（目前使用 JDK 1.6.0_07。）
采纳答案by VonC
This is really linked to HotSpotand the default option values(Java HotSpot VM Options) which differ between client and server configuration.
这实际上与HotSpot和默认选项值（Java HotSpot VM Options）有关，它们在客户端和服务器配置之间有所不同。
From Chapter 2of the whitepaper (The Java HotSpot Performance Engine Architecture):
来自白皮书的第 2 章（Java HotSpot 性能引擎架构）：
The JDK includes two flavors of the VM -- a client-side offering, and a VM tuned for server applications. These two solutions share the Java HotSpot runtime environment code base, but use different compilers that are suited to the distinctly unique performance characteristics of clients and servers. These differences include the compilation inlining policy and heap defaults.
Although the Server and the Client VMs are similar, the Server VM has been specially tuned to maximize peak operating speed. It is intended for executing long-running server applications, which need the fastest possible operating speed more than a fast start-up time or smaller runtime memory footprint.
The Client VM compiler serves as an upgrade for both the Classic VM and the just-in-time (JIT) compilers used by previous versions of the JDK. The Client VM offers improved run time performance for applications and applets. The Java HotSpot Client VM has been specially tuned to reduce application start-up time and memory footprint, making it particularly well suited for client environments. In general, the client system is better for GUIs.
JDK 包括两种类型的 VM——客户端产品和针对服务器应用程序调整的 VM。这两个解决方案共享 Java HotSpot 运行时环境代码库，但使用不同的编译器，以适应客户端和服务器明显独特的性能特征。这些差异包括编译内联策略和堆默认值。
尽管服务器和客户端 VM 相似，但服务器 VM 已经过专门调整以最大限度地提高峰值运行速度。它旨在执行长时间运行的服务器应用程序，这些应用程序需要尽可能快的运行速度，而不是快速启动时间或较小的运行时内存占用。
客户端 VM 编译器用作经典 VM 和 JDK 以前版本使用的即时 (JIT) 编译器的升级。客户端 VM 为应用程序和小程序提供改进的运行时性能。Java HotSpot 客户端 VM 已经过专门调整以减少应用程序启动时间和内存占用，使其特别适合客户端环境。一般来说，客户端系统更适合 GUI。
So the real difference is also on the compiler level:
所以真正的区别还在于编译器级别：
The Client VM compiler does not try to execute many of the more complex optimizations performed by the compiler in the Server VM, but in exchange, it requires less time to analyze and compile a piece of code. This means the Client VM can start up faster and requires a smaller memory footprint.
The Server VM contains an advanced adaptive compiler that supports many of the same types of optimizations performed by optimizing C++ compilers, as well as some optimizations that cannot be done by traditional compilers, such as aggressive inlining across virtual method invocations. This is a competitive and performance advantage over static compilers. Adaptive optimization technology is very flexible in its approach, and typically outperforms even advanced static analysis and compilation techniques.
Client VM 编译器不会尝试执行许多由 Server VM 中的编译器执行的更复杂的优化，但作为交换，它分析和编译一段代码所需的时间更少。这意味着客户端 VM 可以更快地启动并且需要更小的内存占用。
服务器 VM 包含一个高级自适应编译器，它支持由优化 C++ 编译器执行的许多相同类型的优化，以及一些传统编译器无法完成的优化，例如跨虚拟方法调用的积极内联。这是相对于静态编译器的竞争和性能优势。自适应优化技术的方法非常灵活，通常甚至优于高级静态分析和编译技术。
Note: The release of jdk6 update 10(see Update Release Notes:Changes in 1.6.0_10) tried to improve startup time, but for a different reason than the hotspot options, being packaged differently with a much smaller kernel.
注意：jdk6 update 10的发布（请参阅更新发行说明：1.6.0_10 中的更改）试图缩短启动时间，但出于与热点选项不同的原因，使用更小的内核进行了不同的打包。
G. Demeckipoints out in the commentsthat in 64-bit versions of JDK, the -clientoption is ignored for many years.
See Windows javacommand:
G. Demecki指出，在评论，在JDK的64位版本，该-client选项是多年来忽视。
请参阅Windowsjava命令：
-client
Selects the Java HotSpot Client VM.
A 64-bit capable JDK currently ignores this option and instead uses the Java Hotspot Server VM.
选择 Java HotSpot 客户端 VM。
支持 64 位的 JDK 当前忽略此选项，而是使用 Java Hotspot Server VM。
回答by Brian Knoblauch
I've not noticed any difference in startup time between the 2, but clocked a very minimal improvement in application performance with "-server" (Solaris server, everyone using SunRays to run the app). That was under 1.5.
我没有注意到 2 之间的启动时间有任何差异，但是使用“-server”（Solaris 服务器，每个人都使用 SunRays 来运行应用程序）对应用程序性能的改进非常小。那是低于 1.5。
回答by Mike Akers
IIRC the server VM does more hotspot optimizations at startup so it runs faster but takes a little longer to start and uses more memory. The client VM defers most of the optimization to allow faster startup.
IIRC 服务器虚拟机在启动时会进行更多的热点优化，因此运行速度更快，但启动时间更长，并使用更多内存。客户端 VM 推迟了大部分优化以实现更快的启动。
Edit to add: Here's some infofrom Sun, it's not very specific but will give you some ideas.
回答by Michael Easter
IIRC, it involves garbage collection strategies. The theory is that a client and server will be different in terms of short-lived objects, which is important for modern GC algorithms.
IIRC，它涉及垃圾收集策略。理论上，客户端和服务器在短期对象方面会有所不同，这对于现代 GC 算法很重要。
Here is a linkon server mode. Alas, they don't mention client mode.
Here is a very thorough linkon GC in general; this is a more basic article. Not sure if either address -server vs -client but this is relevant material.
这里有一个关于 GC的非常详尽的链接；这是一篇比较基础的文章。不确定地址是 -server 还是 -client，但这是相关材料。
At No Fluff Just Stuff, both Ken Sipe and Glenn Vandenburg do great talks on this kind of thing.
在 No Fluff Just Stuff，Ken Sipe 和 Glenn Vandenburg 就这类事情做了精彩的演讲。
回答by prule
One difference I've just noticed is that in "client" mode, it seems the JVM actually gives some unused memory back to the operating system, whereas with "server" mode, once the JVM grabs the memory, it won't give it back. Thats how it appears on Solaris with Java6 anyway (using prstat -Zto see the amount of memory allocated to a process).
我刚刚注意到的一个区别是，在“客户端”模式下，JVM 似乎实际上将一些未使用的内存返还给操作系统，而在“服务器”模式下，一旦 JVM 获取内存，它就不会给它背部。这就是它在带有 Java6 的 Solaris 上的显示方式（prstat -Z用于查看分配给进程的内存量）。
回答by Mark Booth
The most visible immediate difference in older versions of Java would be the memory allocated to a -clientas opposed to a -serverapplication. For instance, on my Linux system, I get:
较旧版本的 Java 中最明显的直接区别是分配给应用程序-client而不是-server应用程序的内存。例如，在我的 Linux 系统上，我得到：
$ 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"
as it defaults to -server, but with the -clientoption I get:
因为它默认为-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"
so with -servermost of the memory limits and initial allocations are much higher for this javaversion.
所以-server这个java版本的大部分内存限制和初始分配要高得多。
These values can change for different combinations of architecture, operating system and jvm version however. Recent versions of the jvm have removed flags and re-moved many of the distinctions between server and client.
然而，这些值可能会因架构、操作系统和 jvm 版本的不同组合而改变。最新版本的 jvm 删除了标志并重新删除了服务器和客户端之间的许多区别。
Remember too that you can see all the details of a running jvmusing jvisualvm. This is useful if you have users who or modules which set JAVA_OPTSor use scripts which change command line options. This will also let you monitor, in real time, heapand permgenspace usage along with lots of other stats.
还要记住，您可以jvm使用jvisualvm. 如果您的用户或模块设置JAVA_OPTS或使用更改命令行选项的脚本，这将非常有用。这还可以让您实时监控堆和永久空间使用情况以及许多其他统计信息。
回答by pharsicle
Oracle's online documentation provides some information for Java SE 7.
Oracle 的在线文档提供了一些有关 Java SE 7 的信息。
On the java – the Java application launcherpage for Windows, the -clientoption is ignored in a 64-bit JDK:
在java –Windows的 Java 应用程序启动器页面上，该-client选项在 64 位 JDK 中被忽略：
Select the Java HotSpot Client VM. A 64-bit capable jdk currently ignores this option and instead uses the Java HotSpot Server VM.
选择 Java HotSpot 客户端 VM。支持 64 位的 jdk 当前忽略此选项，而是使用 Java HotSpot Server VM。
However (to make things interesting), under -serverit states:
然而（为了让事情变得有趣），在-server它下面指出：
Select the Java HotSpot Server VM. On a 64-bit capable jdk only the Java HotSpot Server VM is supported so the -server option is implicit. This is subject to change in a future release.
选择 Java HotSpot 服务器虚拟机。在支持 64 位的 jdk 上，仅支持 Java HotSpot 服务器 VM，因此 -server 选项是隐式的。这在未来的版本中可能会发生变化。
The Server-Class Machine Detectionpage gives information on which VM is selected by OS and architecture.
该服务器级计算机检测页面给出了其虚拟机OS和体系结构选择的信息。
I don't know how much of this applies to JDK 6.
我不知道这有多少适用于 JDK 6。
回答by brice
Last time I had a look at this, (and admittedly it was a while back) the biggest difference I noticed was in the garbage collection.
上次我看到了这个，（不可否认，那是很久以前的事了）我注意到的最大区别在于垃圾收集。
IIRC:
国际研究中心：
- The server heap VM has a differnt number of generations than the Client VM, and a different garbage collection algorithm. This may not be true anymore
- The server VM will allocate memory and not release it to the OS
- The server VM will use more sophisticated optimisation algorithms, and hence have bigger time and memory requirements for optimisation
- 服务器堆 VM 的代数与客户端 VM 不同，垃圾收集算法也不同。这可能不再是真的
- 服务器虚拟机将分配内存而不将其释放给操作系统
- 服务器虚拟机将使用更复杂的优化算法，因此需要更多的时间和内存进行优化
If you can compare two java VMs, one client, one server using the jvisualvmtool, you should see a difference in the frequency and effect of the garbage collection, as well as in the number of generations.
如果您可以使用jvisualvm工具比较两台 Java 虚拟机、一台客户端、一台服务器，您应该会看到垃圾收集的频率和效果以及代数方面的差异。
I had a pair of screenshots that showed the difference really well, but I can't reproduce as I have a 64 bit JVM which only implements the server VM. (And I can't be bothered to download and wrangle the 32 bit version on my system as well.)
我有一对屏幕截图很好地显示了差异，但我无法重现，因为我有一个 64 位 JVM，它只实现了服务器 VM。（而且我也懒得在我的系统上下载和争论 32 位版本。）
This doesn't seem to be the case anymore, having tried running some code on windows with both server and client VMs, I seem to get the same generation model for both...
情况似乎不再如此，尝试在服务器和客户端 VM 的 Windows 上运行一些代码后，我似乎为两者获得了相同的生成模型......
回答by Nuwan Arambage
When doing a migration from 1.4 to 1.7("1.7.0_55") version.The thing that we observed here is, there is no such differences in default values assigned to heapsize|permsize|ThreadStackSize parameters in client & server mode.
当从 1.4 迁移到 1.7("1.7.0_55") 版本时。我们在这里观察到的是，在客户端和服务器模式下分配给 heapsize|permsize|ThreadStackSize 参数的默认值没有这种差异。
By the way, (http://www.oracle.com/technetwork/java/ergo5-140223.html). This is the snippet taken from above link.
顺便说一句，（http://www.oracle.com/technetwork/java/ergo5-140223.html）。这是从上面的链接中截取的片段。
initial heap size of 1/64 of physical memory up to 1Gbyte
maximum heap size of ? of physical memory up to 1Gbyte
ThreadStackSize is higher in 1.7, while going through Open JDK forum,there are discussions which stated frame size is somewhat higher in 1.7 version. It is believed real difference could be possible to measure at run time based on your behavior of your application
ThreadStackSize 在 1.7 中更高，在通过 Open JDK 论坛时，有讨论表明 1.7 版本中的帧大小略高。相信可以根据应用程序的行为在运行时测量真正的差异
回答by Premraj
the -client and -server systems are different binaries. They are essentially two different compilers (JITs) interfacing to the same runtime system. The client system is optimal for applications which need fast startup times or small footprints, the server system is optimal for applications where the overall performance is most important. In general the client system is better suited for interactive applications such as GUIs
-client 和 -server 系统是不同的二进制文件。它们本质上是两个不同的编译器 (JIT)，它们连接到同一个运行时系统。客户端系统最适合需要快速启动时间或占用空间小的应用程序，服务器系统最适合需要整体性能最重要的应用程序。一般来说，客户端系统更适合交互式应用程序，例如 GUI
We run the following code with both switches:
我们使用两个开关运行以下代码：
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--) {
}
}
}
Note:The code is been compiled only once! The classes are the same in both runs!
注意：代码只编译一次！两次运行中的类是相同的！
With -client:
java.exe -client -classpath C:\mywork\classes com.blogspot.sdoulger.LoopTest
Time spent: 766
使用 -client:
java.exe -client -classpath C:\mywork\classes com.blogspot.sdoulger.LoopTest
耗时：766
With -server:
java.exe -server -classpath C:\mywork\classes com.blogspot.sdoulger.LoopTest
Time spent: 0
使用 -server:
java.exe -server -classpath C:\mywork\classes com.blogspot.sdoulger.LoopTest
花费的时间：0
It seems that the more aggressive optimazation of the server system, remove the loop as it understands that it does not perform any action!
似乎服务器系统的更积极优化，删除循环，因为它明白它不执行任何操作！
