Differenze reali tra "java-server"e" java-client"?

La differenza immediata più visibile nelle versioni precedenti di Java sarebbe la memoria allocata a un'applicazione -client anziché a un'applicazione -server. Ad esempio, sul mio sistema Linux, ottengo:

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

Come predefinito -server, ma con l'opzione -client ottengo:

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

Quindi con -server la maggior parte dei limiti di memoria e delle allocazioni iniziali sono molto più alti per questa versione java.

Questi valori possono cambiare per diverse combinazioni di architettura, sistema operativo e jvm versione tuttavia. Le versioni recenti della jvm hanno rimosso i flag e spostato molte delle distinzioni tra server e client.

Ricorda anche che puoi vedere tutti i dettagli di un jvm in esecuzione usando jvisualvm. Questo è utile se hai utenti che o moduli che impostano JAVA_OPTS o usano script che cambiano le opzioni della riga di comando. Questo ti permetterà anche di monitorare, in tempo reale, heap e permgen utilizzo dello spazio insieme a molte altre statistiche.

Una differenza che ho appena notato è che in modalità "client", sembra che la JVM restituisca effettivamente una memoria inutilizzata al sistema operativo - mentre con la modalità "server", una volta che la JVM afferra la memoria, non la restituirà. Ecco come appare su Solaris con Java6 comunque (usando prstat-Z per vedere la quantità di memoria allocata a un processo).

I sistemi-client e-server sono binari diversi. Sono essenzialmente due compilatori diversi (JIT) che si interfacciano allo stesso sistema di runtime. Il sistema client è ottimale per le applicazioni che necessitano di tempi di avvio rapidi o piccole impronte, il sistema server è ottimale per le applicazioni in cui le prestazioni complessive sono più importanti. In generale il sistema client è più adatto per applicazioni interattive come GUI

Eseguiamo quanto segue codice con entrambi gli interruttori:

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

Nota: Il codice è stato compilato una sola volta! Le classi sono le stesse in entrambe le esecuzioni!

Con-cliente:
Java.exe-client-classpath C:\mywork\classes com.blogspot.sdoulger.LoopTest
Tempo trascorso: 766

Con-server:
Java.exe - server-classpath C:\mywork\classes com.blogspot.sdoulger.LoopTest
Tempo trascorso: 0

Sembra che l'optimazation più aggressiva del server sistema, rimuovere il ciclo in quanto capisce che non esegue alcuna azione!

Riferimento

La documentazione online di Oracle fornisce alcune informazioni per Java SE 7.

Nella pagina java-avvio applicazioni Java per Windows, l'opzione -client viene ignorata in un JDK a 64 bit:

Selezionare la VM client Java HotSpot. Un jdk a 64 bit attualmente ignora questa opzione e utilizza invece la VM Java HotSpot Server.

Tuttavia (per rendere le cose interessanti), sotto -server si afferma:

Selezionare la VM Java HotSpot Server. Su un jdk a 64 bit è supportata solo la VM Java HotSpot Server, quindi l'opzione-server è implicita. Questo è soggetto a modifiche in una versione futura.

La pagina Server-Class Machine Detection fornisce informazioni su quale VM è selezionata dal sistema operativo e dall'architettura.

Non lo so quanto di questo si applica a JDK 6.

IIRC la VM del server esegue più ottimizzazioni dell'hotspot all'avvio, quindi funziona più velocemente ma richiede un po ' più di tempo per l'avvio e utilizza più memoria. La VM client rinvia la maggior parte dell'ottimizzazione per consentire un avvio più rapido.

Modifica per aggiungere: Ecco alcune informazioni da Sun, non è molto specifico ma ti darà alcune idee.

Dalla concorrenza Goetz - Java in pratica:

1. Suggerimento per il debug: per le applicazioni server, assicurarsi di specificare sempre l'opzione della riga di comando JVM-server quando si richiama la JVM, anche per sviluppo e test. Il server JVM esegue più ottimizzazione rispetto alla JVM client, come il sollevamento di variabili da un ciclo che sono non modificato nel ciclo; codice che potrebbe sembrare funzionare nel l'ambiente di sviluppo (client JVM) può interrompere la distribuzione ambiente (server JVM). Ad esempio, avevamo "dimenticato" di dichiarare la variabile addormentata come volatile nel listato 3.4, la JVM del server potrebbe sollevare il test dal ciclo (trasformandolo in un ciclo infinito), ma la JVM client non avrebbe . Un ciclo infinito che si presenta in lo sviluppo è molto meno costoso di uno che si presenta solo in produzione.

Elenco 3.4. Contare le pecore.

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

La mia enfasi. YMMV

IIRC, coinvolge strategie di garbage collection. La teoria è che un client e un server saranno diversi in termini di oggetti di breve durata, il che è importante per i moderni algoritmi GC.

Ecco un link in modalità server. Ahimè, non menzionano la modalità client.

Ecco un link molto approfonditosu GC in generale; questo è un articolo più fondamentale. Non sono sicuro se l'indirizzo-server vs-client ma questo è materiale rilevante.

Senza lanugine Solo Roba, sia Ken Sipe che Glenn Vandenburg fanno grandi discorsi su questo genere di cose.

Non ho notato alcuna differenza nel tempo di avvio tra 2, ma ho registrato un miglioramento minimo delle prestazioni dell'applicazione con "-server" (server Solaris, tutti quelli che usano SunRays per eseguire l'app). Era sotto 1,5.

L'ultima volta che ho dato un'occhiata a questo, (e certamente era un po ' indietro) la più grande differenza che ho notato era nella raccolta dei rifiuti.

IRC:

• La VM heap del server ha un numero di generazioni diverso rispetto alla VM client e un algoritmo di garbage collection diverso. Questo potrebbe non essere più vero
• La VM del server allocherà la memoria e non la rilascerà al sistema operativo
• La VM del server utilizzerà algoritmi di ottimizzazione più sofisticati, e quindi avere maggiori requisiti di tempo e memoria per l'ottimizzazione

Se è possibile confrontare due macchine virtuali java, un client, un server utilizzando lo strumento jvisualvm , si dovrebbe vedere una differenza nella frequenza e nell'effetto della garbage collection, nonché nel numero di generazioni.

Ho avuto un paio di screenshot che hanno mostrato la differenza molto bene, ma non riesco a riprodurre dato che ho una JVM a 64 bit che implementa solo la VM del server. (E non posso essere disturbato da scarica e disputare anche la versione a 32 bit sul mio sistema.)

Questo non sembra essere più il caso, dopo aver provato a eseguire del codice su Windows con VM server e client, mi sembra di ottenere lo stesso modello di generazione per entrambi...

Quando si esegue una migrazione dalla versione 1.4 alla versione 1.7("1.7.0_55").La cosa che abbiamo osservato qui è che non ci sono tali differenze nei valori predefiniti assegnati ai parametri heapsize|permsize|ThreadStackSize in modalità client e server.

A proposito, ( http://www.oracle.com/technetwork/java/ergo5-140223.html). Questo è il frammento preso dal link sopra.

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

ThreadStackSize è più alto in 1.7, mentre passa attraverso il forum JDK aperto, ci sono discussioni che hanno dichiarato frame la dimensione è leggermente superiore nella versione 1.7. Si ritiene che la vera differenza potrebbe essere possibile misurare in fase di esecuzione in base al comportamento dell'applicazione