Echte Unterschiede zwischen „Java-Server“ und „Java-Client“?

https://stackoverflow.com/questions/198577

10-07-2019
|

Frage

Gibt es einen wirklichen praktischen Unterschied zwischen „Java-Server“ und „Java-Client“?

Alles, was ich auf Suns Website finden kann, ist vage

„-server startet langsamer, sollte aber schneller laufen“.

Was sind die wirklichen Unterschiede?(Verwendet derzeit JDK 1.6.0_07.)

Lösung

Das ist wirklich im Zusammenhang mit HotSpot und dem Standard Optionswerte ( Java HotSpot VM-Optionen ), die zwischen Client und Server-Konfiguration unterschiedlich sein.

Kapitel 2 des White Paper ( Die Java HotSpot Performance Engine Architecture ):

Das JDK enthält zwei Varianten der VM - ein clientseitiges Angebot und eine VM für Server-Anwendungen abgestimmt. Diese beiden Lösungen teilen sich die Java HotSpot-Laufzeitumgebung Code-Basis, jedoch mit anderen Compilern, die auf die deutlich einzigartigen Leistungsmerkmale von Clients und Servern geeignet sind. Diese Unterschiede umfassen die Erstellung inlining Politik und Heap-Standardwerte.

Obwohl die Server und der Client-VMs ähnlich sind, hat der Server VM speziell abgestimmt worden Spitzenbetriebsgeschwindigkeit zu maximieren. Es ist beabsichtigt, für die Ausführung mit langer Laufzeit-Server-Anwendungen, die die schnellstmögliche Arbeitsgeschwindigkeit mehr als eine schnelle Startzeit oder kleinere Laufzeitspeicherbedarf benötigen.

Der Client-VM Compiler dient als Upgrade für beide den Classic-VM und die Just-in-Time (JIT) Compiler von früheren Versionen des JDK verwendet. Der Client-VM bietet eine verbesserte Laufzeit-Performance für Anwendungen und Applets. Das Java HotSpot VM-Client wurde speziell abgestimmte Anwendung Startzeit und Speicherbedarf zu reduzieren, ist es besonders gut geeignet für die Client-Umgebungen. Im Allgemeinen ist das Client-System besser für GUIs.

So ist der wirkliche Unterschied ist, auch auf der Compiler-Ebene:

Der Client-VM Compiler versucht nicht durch den Compiler in dem Server-VM, aber im Austausch durchgeführt viele der komplexeren Optimierungen durchzuführen, erfordert es weniger Zeit, ein Stück Code zu analysieren und zu kompilieren. Dies bedeutet, dass die Client-VM kann schneller starten und erfordert einen kleineren Speicherbedarf.

Der Server VM enthält eine erweiterte adaptive Compiler, sowie einige Optimierungen durch die Optimierung der C ++ Compiler durchgeführt viele der gleichen Arten von Optimierungen unterstützt, die durch traditionelle Compiler, wie aggressive inlining über virtuelle Methodenaufrufe erfolgen kann nicht sein. Dies ist ein wettbewerbsfähiger und Leistungsvorteil gegenüber statischen Compiler. Adaptive-Optimierungs-Technologie ist sehr flexibel in ihrem Ansatz und in der Regel übertrifft sogar erweitern statische Analyse und Übersetzungstechniken.

Hinweis: Die Veröffentlichung von jdk6 aktualisieren 10 (siehe Update Release Notes: Änderungen in 1.6.0_10 ) versucht, die Startzeit zu verbessern, aber aus einem anderen Grund als die Hotspot-Optionen, wobei andere Weise verpackt sind mit einem viel kleineren Kernel

G. Demecki weist darauf hin, in Kommentare , dass in 64-Bit-Versionen von JDK wird die -client Option für viele Jahre ignoriert.
Siehe Windows-java Befehl :

-client

Wählt die Java HotSpot Client-VM.
Ein 64-Bit-fähig JDK ignoriert derzeit diese Option und verwendet stattdessen den Java Hotspot Server VM .

Andere Tipps

Der sichtbarste Unterschied sofort in älteren Versionen von Java würde der Speicher zu einem -client zugeordnet sein, wie an eine -server Anwendung gegenüber. Zum Beispiel auf meinem Linux-System, erhalte ich:

$ 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"

, wie es standardmäßig -server, aber mit der Option -client erhalte ich:

$ 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 mit -server meisten der Speichergrenzen und Erstzuteilungen viel höher für diese java Version sind.

Diese Werte können für verschiedene Kombinationen von Architektur ändern, Betriebssysteme und Jvm Versionen jedoch. Neuere Versionen des Jvm entfernt haben Fahnen und viele der Unterschiede zwischen Server und Client entfernt.

Beachten Sie auch, dass Sie alle Details eines laufenden jvm mit jvisualvm sehen können. Dies ist nützlich, wenn Sie Benutzer, die oder Module, die JAVA_OPTS oder Verwendung Skripte gesetzt, die Befehlszeilenoptionen ändern. Dies wird auch Sie überwachen, in Echtzeit, heap und Permgen Raumnutzung zusammen mit vielen anderen Statistiken.

Ein Unterschied, den ich gerade bemerkt habe ist, dass in „Client“ -Modus, den JVM scheint tatsächlich etwas ungenutzten Speicher gibt zurück an das Betriebssystem, während mit „Server“ Modus, sobald die JVM die Erinnerung packt, es gewann‘ t gibt es zurück. Das ist, wie es auf Solaris mit Java6 erscheint sowieso (mit prstat -Z die Größe des Speichers zu einem Prozess zugeordnet sehen).

die -Client und -Server-Systeme sind verschiedene Binärdateien. Sie sind im Wesentlichen zwei unterschiedliche Compiler (JIT) auf demselben Laufzeitsystem einer Schnittstelle. Das Client-System für Anwendungen optimal ist, die eine schnelle Startzeiten oder kleine Fußabdrücke benötigen, ist das Server-System optimal für Anwendungen, bei denen die Gesamtleistung am wichtigsten ist. Im Allgemeinen ist das Client-System besser geeignet für interaktive Anwendungen wie GUIs

Wir führen Sie den folgenden Code mit beiden Schaltern:

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--) {
        }
    }
}

Hinweis: Der Code wird nur einmal zusammengestellt! Die Klassen sind die gleichen in beiden Läufen!

Mit -client:
java.exe -client -classpath C: \ mywork \ classes com.blogspot.sdoulger.LoopTest
Verbrachte Zeit: 766

Mit -Server:
java.exe -Server -classpath C: \ mywork \ classes com.blogspot.sdoulger.LoopTest
Verbrachte Zeit: 0

Es scheint, dass die aggressiveren optimazation des Serversystems, die Schleife entfernen, da sie weiß, dass es keine Aktion durchführen!

Referenz

Oracle Online-Dokumentation bietet einige Informationen für Java SE 7.

Auf der Java - Java-Anwendungs-Launcher -Seite für Windows wird die -client Option in einem 64-Bit-JDK ignoriert:

Wählen Sie die Java HotSpot Client-VM. Ein 64-Bit-fähig jdk ignoriert derzeit diese Option und verwendet stattdessen die Java HotSpot VM Server.

Allerdings (um die Dinge interessant), unter -server heißt es:

Wählen Sie die Java HotSpot VM Server. Auf einem 64-Bit-fähig jdk nur der Java HotSpot VM Server unterstützt, so dass die Option -server implizit ist. Dies ist Thema in einer zukünftigen Version ändern.

Die Server-Class-Maschine Erkennung Seite gibt Auskunft auf dem VM von OS und Architektur ausgewählt.

Ich weiß nicht, wie viel dies gilt für JDK 6.

IIRC den Server VM mehr Hotspot Optimierungen beim Start tut, damit es schneller läuft dauert aber etwas länger zu starten und mehr Speicher verwendet. Die Client-VM aufschiebt die meisten der Optimierung schnellere Inbetriebnahme zu ermöglichen.

Bearbeiten hinzuzufügen: Hier ein paar Informationen von Sun , ist es nicht sehr spezifisch, aber sie einige Ideen geben.

Von Goetz - Java Concurrency in der Praxis:

Debuggen Tipp: Für Serveranwendungen, sollten Sie immer die -server JVM-Befehlszeilenoption angeben, wenn die JVM aufrufen, auch für   Entwicklung und Erprobung . Der Server JVM führt weitere Optimierung   als der Client JVM, wie Variablen aus einer Schleife, die Hebe   nicht in der Schleife modifiziert; Code, der in dem erscheinen könnte arbeiten   Entwicklungsumgebung (Client JVM) kann in der Bereitstellung brechen   -Umgebung (Server JVM). Zum Beispiel hatten wir „vergessen“ zu erklären   die Variable schlafend als flüchtig in Listing 3.4, der Server JVM konnte   Flaschenzug den Test aus der Schleife (es in eine Endlosschleife dreht), aber   der Client-JVM würde nicht . Eine Endlosschleife, die nach oben zeigt, in   Entwicklung ist weit weniger kostspielig als eine, die nur zeigt sich in   Produktion.


Listing 3.4. Schafe zählen.

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

Mein Schwerpunkt. YMMV

IIRC, es beinhaltet die Garbage Collection-Strategien. Die Theorie ist, dass ein Client und Server werden in Bezug auf den kurzlebigen Objekten unterschiedlich sein, die für die modernen GC-Algorithmen wichtig ist.

Hier ist ein Link auf Server-Modus. Ach, sie nicht erwähnen, Client-Modus.

Hier ist ein sehr gründlicher Link auf GC im Allgemeinen; dies ist ein rel="noreferrer">. Nicht sicher, ob entweder Adresse -Server vs -client aber das ist relevantes Material.

Bei No Fluff Gerade Stuff, beide Ken Sipe und Glenn Vandenburg zu tun große Gespräche über diese Art der Sache.

Ich habe keinen Unterschied in Startzeit zwischen 2 bemerkt, aber eine sehr geringe Verbesserung der Anwendungsleistung mit „-Server“ (Solaris-Server, jeder mit SunRays die App läuft) getaktet. Das war unter 1,5.

Das letzte Mal hatte ich einen Blick auf diese (und zugegebenermaßen war es eine Weile zurück) der größte Unterschied war ich in der Garbage Collection bemerkt.

IIRC:

Der Server Heap VM hat eine differnt Anzahl von Generationen als der Client-VM, und einen anderen Speicherbereinigungsalgorithmus. Das kann nicht mehr wahr sein
Der Server VM Speicher zuweisen und es nicht loslassen, um das Betriebssystem
Der Server VM komplexere Optimierungsalgorithmen verwenden und damit größere Zeit- und Speicheranforderungen haben zur Optimierung

~~Wenn Sie zwei Java-VMs vergleichen, ein Client, ein Server mit dem~~ ~~jvisualvm Werkzeug, Sie sollen einen Unterschied in der Häufigkeit und die Wirkung der Garbage collection sowie in der Anzahl der Generationen sehen.~~

ich ein Paar Screenshots hatte, die den Unterschied wirklich gut zeigte, aber ich kann nicht reproduzieren, wie ich eine 64-Bit-JVM haben, die den Server VM nur implementiert. (Und ich kann nicht gestört werden, zum Download und hadert die 32-Bit-Version auf meinem System als auch.)

Dies scheint nicht mehr der Fall zu sein, versucht zu haben, auf Windows einige Code ausgeführt wird mit Server und Client VMs, scheine ich die gleiche Generation Modell für beide zu bekommen ...

Bei einer Migration von Version 1.4 auf Version 1.7 („1.7.0_55“). Was wir hier beobachtet haben, ist, dass es keine derartigen Unterschiede bei den Standardwerten gibt, die den Parametern „heapsize|permsize|ThreadStackSize“ im Client- und Servermodus zugewiesen werden.

Übrigens, (http://www.oracle.com/technetwork/java/ergo5-140223.html).Dies ist der Ausschnitt aus dem obigen Link.

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

ThreadStackSize ist in Version 1.7 höher. Im Open JDK-Forum gab es Diskussionen, die besagten, dass die Frame-Größe in Version 1.7 etwas höher sei.Man geht davon aus, dass ein echter Unterschied zur Laufzeit anhand des Verhaltens Ihrer Anwendung gemessen werden kann

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow