Scrittura Java a bassa latenza [chiuso]

Esistono tecniche specifiche di Java (cose che non si applicano al C ++) per scrivere codice a bassa latenza, in Java? Vedo spesso ruoli a bassa latenza Java e mi chiedono esperienza nella scrittura di Java a bassa latenza, che a volte sembra un po 'un ossimoro.

L'unica cosa che mi viene in mente è l'esperienza con JNI, esternalizzando le chiamate I / O al codice nativo. Probabilmente utilizza anche il modello di disgregatore, ma questa non è una vera tecnologia.

Esistono suggerimenti specifici per Java per la scrittura di codice a bassa latenza?

Sono consapevole che esiste una specifica Java in tempo reale, ma sono stato avvisato in tempo reale non è lo stesso della bassa latenza ....

Oltre ai commenti di Martijn aggiungerei:

1. Riscalda la tua JVM. L'avvio di Bytecode inizia come viene interpretato per Hotspot e quindi viene compilato sul server dopo 10K osservazioni . La compilazione a livelli può essere un buon gap.

2. Il classloading è un processo sequenziale che coinvolge IO su disco. Assicurarsi che tutte le classi per i flussi delle transazioni principali siano caricate in anticipo e che non vengano mai sfrattate dalla generazione di perm.

3. Segui il " Principio del singolo scrittore " per evitare la contesa e le implicazioni dell'effetto di accodamento della Legge di Little, oltre a studiare la Legge di Amdhal per ciò che può essere parallelo e ne vale la pena.

4. Modella il tuo dominio aziendale e assicurati che tutti i tuoi algoritmi siano O (1) o almeno O (log n). Questa è probabilmente la principale causa di problemi di prestazioni nella mia esperienza. Assicurarsi di disporre di test delle prestazioni per coprire i casi principali.

5. La bassa latenza in Java non si limita solo a Java. Devi capire l'intero stack sul quale il tuo codice è in esecuzione. Ciò comporterà l'ottimizzazione del sistema operativo, la selezione dell'hardware appropriato, il software dei sistemi di ottimizzazione e i driver di dispositivo per tale hardware.

6. Sii realista. Se è necessaria una latenza bassa, non eseguire un hypervisor. Assicurarsi di disporre di core sufficienti per tutti i thread che devono trovarsi nello stato eseguibile.

7. I cache miss sono il costo maggiore per le prestazioni. Utilizzare algoritmi compatibili con la cache e impostare l'affinità con i core del processore con tasket o numactl per una JVM o JNI per i singoli thread.

8. Prendi in considerazione una JVM alternativa come Zing di Azul con un garbage collector senza pause.

9. Soprattutto coinvolgere qualcuno con l'esperienza. Questo ti farà risparmiare così tanto tempo nel lungo periodo. Spina senza vergogna :-)

Il tempo reale e la bassa latenza sono soggetti nettamente separati sebbene spesso correlati. In tempo reale si tratta di essere più prevedibili che veloci. Nella mia esperienza, le JVM in tempo reale, anche quelle soft in tempo reale, sono più lente delle normali JVM.

Ci sono un sacco di cose di cui tenere conto di sì. Al momento sono a Creta con accesso limitato alla rete, quindi sarà (abbastanza) breve. Inoltre, non sono un esperto a bassa latenza, ma molti dei miei colleghi ne giocano uno nella vita reale :-).

1. Devi apprezzare la simpatia meccanica (un termine coniato da Martin Thompson ). In altre parole, devi capire cosa sta facendo l'hardware sottostante. Sapere come le CPU caricano le linee della cache, qual è la loro larghezza di banda in lettura / scrittura, la velocità della memoria principale e molto, molto altro è molto importante. Perché? Perché dovrai ragionare su come il tuo codice sorgente Java influenza il Sistema Operativo / Hardware tramite la JVM di runtime. Ad esempio, è il modo in cui le variabili di campo sono disposte nel codice sorgente causando gli sfratti della linea di cache (costa circa 150 cicli di clock), hmmm ... :-).

2. Generalmente si desidera disporre di algoritmi e I / O senza blocco. Anche l'applicazione concorrente più ben progettata (che utilizza i blocchi) è a rischio di blocco, il blocco a bassa latenza è generalmente negativo :-).

3. Comprendere l'allocazione degli oggetti e la Garbage Collection. Questo è un argomento enorme, ma in sostanza vuoi evitare le pause GC (spesso causate dalla natura Stop the World di varie raccolte GC). Collezionisti GC specialisti come il collezionista Azul possono in molti casi risolvere questo problema per te immediatamente, ma per la maggior parte delle persone devono capire come mettere a punto i GC Sun / Oracle (CMS, G1, ecc.).

4. L'Hotspot JIT è davvero incredibile. Scopri le sue ottimizzazioni, ma in generale tutte le buone tecniche OO (incapsulamento, piccoli metodi, quanti più dati immutabili possibili) permetteranno a JIT di ottimizzare, dandoti il ​​tipo di livelli di prestazioni che ti offre il codice C / C ++ ben realizzato.

5. Architettura di sistema complessiva. Fai attenzione alla rete, al modo in cui le macchine sono collocate, se sei connesso allo scambio tramite fibra, ecc. Ecc.

6. Essere consapevoli dell'impatto della registrazione. la registrazione binaria o l'utilizzo di un output codificato che è possibile analizzare off line è probabilmente una buona idea.

Nel complesso consiglio vivamente di frequentare il corso di messa a punto delle prestazioni Java di Kirk Pepperdine [Disclaimer: insegno questo corso da solo, quindi sono parziale]. Otterrai una buona copertura dei vari aspetti della JVM e del suo impatto su O / S e hardware sottostanti.

PS: Proverò a rivederlo più tardi e a riordinarlo un po '.