“java -server”和“java -client”之间的真正区别?

Is there any real practical difference between "java -server" and "java -client"? All I can find on Sun's site is a vague "-server starts slower but should run faster". What are the real differences? (Using JDK 1.6.0_07 currently.)

“java -server”和“java -client”有什么实际区别吗?我能在Sun的网站上找到的只是一个模糊的“-服务器启动更慢，但应该运行得更快”。真正的区别是什么?(目前使用JDK 1.6.0_07。)

11 个解决方案

#1

This is really linked to HotSpot and the default option values (Java HotSpot VM Options) which differ between client and server configuration.

这实际上是与HotSpot和默认选项值(Java HotSpot VM选项)相关联的，这些值在客户机和服务器配置之间存在差异。

From Chapter 2 of 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.

JDK包括两个版本的VM——一个客户端产品和一个用于服务器应用程序的VM。这两个解决方案共享Java HotSpot运行时环境代码库，但是使用不同的编译器，这些编译器适合于客户端和服务器的独特的性能特征。这些差异包括编译内联策略和堆默认值。

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.

虽然服务器和客户端VM是相似的，但是服务器VM经过了特殊的调优，以最大限度地提高运行速度。它用于执行长时间运行的服务器应用程序，这些应用程序需要比快速启动时间或更小的运行时内存占用更大的运行速度。

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.

客户端VM编译器可以作为JDK的早期版本使用的经典VM和即时(JIT)编译器的升级。客户端VM为应用程序和applet提供了改进的运行时性能。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.

客户端VM编译器不尝试执行服务器VM中编译器执行的许多更复杂的优化，但是作为交换，它需要更少的时间来分析和编译一段代码。这意味着客户端VM可以更快地启动，并且需要更小的内存占用。

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.

服务器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中的更改)试图改进启动时间，但是由于与hotspot选项不同的原因，用更小的内核进行不同的打包。

---

G. Demecki points out in the comments that in 64-bit versions of JDK, the -client option is ignored for many years.
See Windows java command:

G. Demecki在评论中指出，在64位JDK版本中，-client选项会被忽略很多年。看到Windows java命令:

-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服务器VM。

#2

The most visible immediate difference in older versions of Java would be the memory allocated to a -client as opposed to a -server application. 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 -client option 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 -server most of the memory limits and initial allocations are much higher for this java version.

因此，对于-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 jvm using jvisualvm. This is useful if you have users who or modules which set JAVA_OPTS or use scripts which change command line options. This will also let you monitor, in real time, heap and permgen space usage along with lots of other stats.

请记住，您可以使用jvisualvm查看运行中的jvm的所有细节。如果您拥有设置JAVA_OPTS或使用更改命令行选项的脚本的用户，这将非常有用。这还允许您实时监视堆和permgen空间的使用以及其他许多统计信息。

#3

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 -Z to see the amount of memory allocated to a process).

我刚刚注意到的一个不同之处是，在“客户端”模式中，JVM实际上将一些未使用的内存返回给操作系统——而在“服务器”模式中，一旦JVM获取了内存，它就不会返回。无论如何，这是在Solaris上使用Java6的方式(使用prstat -Z来查看分配给一个进程的内存数量)。

#4

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

客户机和服务器系统是不同的二进制文件。它们本质上是两个不同的编译器(JITs)与相同的运行时系统进行交互。客户端系统是最优的应用程序，需要快速启动时间或小的足迹，服务器系统是最优的应用程序，其中的整体性能是最重要的。通常，客户端系统更适合交互式应用程序，如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

客户:java。客户端类路径C:\工作类com.blogspot.sdoulger。loopt时间:766

With -server:
java.exe -server -classpath C:\mywork\classes com.blogspot.sdoulger.LoopTest
Time spent: 0

- server:java。服务器类路径C:\工作类com.blogspot.sdoulger。loopt时间: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!

似乎服务器系统的优化越激进，就会删除循环，因为它知道它不执行任何操作!

Reference

参考

#5

Oracle’s online documentation provides some information for Java SE 7.

Oracle的在线文档为Java SE 7提供了一些信息。

On the java – the Java application launcher page for Windows, the -client option is ignored in a 64-bit JDK:

在java - Windows的java应用程序启动页面上，在64位JDK中忽略-client选项:

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服务器VM。

However (to make things interesting), under -server it states:

然而(为了使事情变得有趣)，在-server it状态下:

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服务器VM。在支持64位jdk的情况下，只支持Java HotSpot服务器VM，因此-server选项是隐式的。这将在以后的版本中进行修改。

The Server-Class Machine Detection page gives information on which VM is selected by OS and architecture.

服务器类机器检测页面提供OS和体系结构选择VM的信息。

I don’t know how much of this applies to JDK 6.

我不知道这其中有多少适用于JDK 6。

#6

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在启动时进行了更多的热点优化，因此运行速度更快，但启动时间更长，使用的内存也更多。客户端VM放弃了大部分优化，以允许更快的启动。

Edit to add: Here's some info from Sun, it's not very specific but will give you some ideas.

编辑添加:这里有一些来自Sun的信息，它不是很具体，但会给你一些想法。

#7

From Goetz - Java Concurrency in Practice:

来自Goetz - Java并发实践:

6. Debugging tip: For server applications, be sure to always specify the -server JVM command line switch when invoking the JVM, even for development and testing. The server JVM performs more optimization than the client JVM, such as hoisting variables out of a loop that are not modified in the loop; code that might appear to work in the development environment (client JVM) can break in the deployment environment (server JVM). For example, had we “forgotten” to declare the variable asleep as volatile in Listing 3.4, the server JVM could hoist the test out of the loop (turning it into an infinite loop), but the client JVM would not. An infinite loop that shows up in development is far less costly than one that only shows up in production.
7. 调试提示:对于服务器应用程序，请确保在调用JVM时始终指定-服务器JVM命令行开关，甚至用于开发和测试。服务器JVM比客户机JVM执行更多的优化，比如从循环中未修改的循环中提升变量;可能在开发环境(客户机JVM)中工作的代码可以在部署环境(服务器JVM)中中断。例如，如果我们“忘记”将在清单3.4中休眠的变量声明为volatile，服务器JVM可以将测试从循环中提升出来(将其转换为无限循环)，但是客户机JVM不会。在开发中出现的无限循环的成本要比只在生产中出现的循环低得多。

Listing 3.4. Counting sheep.

清单3.4。数羊。

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

不稳定的布尔睡着了;…而(!睡着了)countSomeSheep();

My emphasis. YMMV

我的重点。YMMV

#8

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 link on server mode. Alas, they don't mention client mode.

这里是服务器模式的链接。唉，他们没有提到客户模式。

Here is a very thorough link on GC in general; this is a more basic article. Not sure if either address -server vs -client but this is relevant material.

下面是关于GC的一个非常全面的链接;这是一篇更基本的文章。不确定是地址-服务器还是客户端，但这是相关材料。

At No Fluff Just Stuff, both Ken Sipe and Glenn Vandenburg do great talks on this kind of thing.

肯·西普和格伦·范登伯格在这方面都做了很好的演讲。

#9

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.

我没有注意到这两款软件在启动时间上有什么不同，但我发现“-server”(Solaris服务器，每个人都使用阳光来运行应用程序)对应用程序性能的改善非常小。这是低于1.5。

#10

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:

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
• 服务器堆VM的代数与客户端VM不同，并且有不同的垃圾收集算法。这也许不再是真的了
• The server VM will allocate memory and not release it to the OS
• 服务器VM将分配内存，而不是将内存释放给操作系统
• The server VM will use more sophisticated optimisation algorithms, and hence have bigger time and memory requirements for optimisation
• 服务器VM将使用更复杂的优化算法，因此对优化有更大的时间和内存需求

If you can compare two java VMs, one client, one server using the jvisualvm tool, you should see a difference in the frequency and effect of the garbage collection, as well as in the number of generations.

如果您可以使用jvisualvm工具对两个java vm(一个客户机、一个服务器)进行比较，那么您应该会看到垃圾收集的频率和效果以及代数的差异。

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...

这似乎已经不是现在的情况了，我已经尝试在windows上同时运行服务器和客户端vm的一些代码，我似乎得到了相同的生成模型。

#11

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版本的框架大小更高。人们认为，根据应用程序的行为，可以在运行时度量真正的差异