Vedo questo parametro in tutti i tipi di posizioni (forum, ecc.) E la risposta comune aiuta i server altamente concorrenti. Tuttavia, non riesco a trovare una documentazione ufficiale da Sun che spieghi cosa fa. Inoltre, è stato aggiunto in Java 6 o esisteva in Java 5?Cos'è Java -XX: + Parametro UseMembar
(a proposito, un buon posto per molti parametri hotspot VM è this page)
Aggiornamento: Java 5 non viene avviato con questo parametro.
Per ottimizzare le prestazioni, la JVM utilizza una "barriera di pseudo memoria" nel codice per fungere da istruzione di scherma durante la sincronizzazione tra più processori. È possibile ripristinare un'istruzione di barriera della memoria "vera", ma ciò può avere un effetto evidente (e negativo) sulle prestazioni.
L'utilizzo di -XX:+UseMembar provoca il ripristino delle istruzioni della barriera di memoria. Originariamente, questo parametro era destinato a esistere temporaneamente come meccanismo di verifica della nuova logica di pseudo-barriera, ma si è scoperto che il nuovo codice di barriera della pseudo-memoria ha introdotto alcuni problemi di sincronizzazione. Credo che ora siano risolti, ma fino a quando non lo sono stati, il modo accettabile per aggirare questi problemi era usare la bandiera reintegrata.
Il bug è stato introdotto in 1.5, e credo che la bandiera esista in 1.5 e 1.6.
ho google-fu'ed questo da una varietà di mailing list e bug JVM:
Quello che non so (e mi piacerebbe) è come funziona il codice di pseudo barriera ... – butterchicken
Vedere anche http: //bugs.sun .com/bugdatabase/view_bug.do? bug_id = 6822370: su cpus e macchine virtuali più recenti con questo bug si possono avere problemi di sincronizzazione molto dispari (risolti in 6u18) – ankon
I don Sono d'accordo con la risposta di Butterchicken. Questa pagina http://www.md.pp.ru/~eu/jdk6options.html dice che questo flag causa l'emissione di barriere di memoria, quindi il thread cambia stato (da RUNNABLE a WAITING o a BLOCKED, ad esempio).
Suppongo che abbiamo bisogno sugli sviluppatori JVM di Sun o rispondere ... –
butterchicken spiega solo metà della storia, vorrei aggiungere maggiori dettagli alla risposta di kmatveev. Sì, l'opzione è per le modifiche allo stato dei thread e vengono utilizzate barriere della memoria (pseudo) per garantire che la modifica sia visibile da altri thread, in particolare il thread VM. Stati filo utilizzato in openjdk6 sono i seguenti:
// _thread_new : Just started, but not executed init. code yet (most likely still in OS init code)
// _thread_in_native : In native code. This is a safepoint region, since all oops will be in jobject handles
// _thread_in_vm : Executing in the vm
// _thread_in_Java : Executing either interpreted or compiled Java code (or could be in a stub)
...
_thread_blocked = 10, // blocked in vm
opzione UseMembar Senza, in Linux, Hotspot utilizza la pagina serializzare memoria invece di istruzioni di barriera di memoria. Ogni volta che si verifica una transizione dello stato del filo, il thread scrive su un indirizzo di memoria nella pagina di serializzazione della memoria con un puntatore volatile. Quando il thread VM deve controllare lo stato aggiornato di tutti i thread, VM cambia i bit di protezione per la pagina serialize della memoria in sola lettura e quindi lo recupera per leggere/scrivere per serializzare le modifiche dello stato. Altro meccanismo dettagliato è introdotto nella pagina seguente:
http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt
UseMembar determina se utilizzare o meno membar istruzioni in modo rigoroso, costringendo tutte le azioni di memoria per completare prima di continuare.
In pratica, si interrompono le ottimizzazioni di gestione della memoria ritardate del processore dall'incombenza del codice.
Questo generalmente rallenta le cose, e non è necessario sulle macchine virtuali moderne per la stragrande maggioranza del codice.
Occasionalmente ci si imbatte in problemi in cui il codice DOVREBBE essere thread-safe, ma non è perché la mancanza di istruzioni di istruzioni per l'uso. In questi casi è possibile attivare questa opzione per far funzionare tale codice senza passare alla modalità single-threading o fare confusione con l'ordinamento del codice per evitare il problema.
La JVM è generalmente in grado di rilevare codice che causerà problemi e inserirà una membrana o eseguirà un riorganizzazione del codice JIT per fornire il tempo necessario al completamento delle operazioni di memoria. Infatti, nella mia ricerca sul web sull'argomento, ho trovato solo un esempio del bug, ed è stato corretto nelle versioni recenti di entrambe le versioni Oracle e OpenJRE dell'hotspot JVM.
Come nota, per le architetture ARM questa opzione è ancora impostata su on, poiché le ottimizzazioni alternative (note come ottimizzazioni psuedo-membar) non sono state ancora applicate, e quindi è soggetta ad essere molto buggata senza le istruzioni di membar.
BTW: Le opzioni -XX non sono ufficialmente supportate e possono essere rimosse da versioni future senza notifica. –
@Rastislav true, ma in molti casi è necessario utilizzarli ... –