"Trovato 1 stallo", ma traccia mostra che non bloccato da qualsiasi thread

La JVM mi dice che si è verificata una situazione di stallo:"Trovato 1 stallo", ma traccia mostra che non bloccato da qualsiasi thread

Found one Java-level deadlock: 
============================= 
"TP-Processor107": 
    waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "indexTrackerThread3" 
"indexTrackerThread3": 
    waiting for ownable synchronizer 0x00002aaaf4394580, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "TP-Processor16" 
"TP-Processor16": 
    waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "indexTrackerThread3"

possiamo vedere che indexTrackerThread3 è in attesa di una risorsa detenuta da TP-Processor16 e vice -versa. Questo è davvero un punto morto.

Possiamo vedere che indexTrackerThread3 è in attesa di 0x00002aaaf4394580:

"indexTrackerThread3": 
    - parking to wait for <0x00002aaaf4394580>

La mia domanda:

In the threads dump, perché non c'è alcuna linea - locked <0x00002aaaf4394580>?

sembra 0x00002aaaf58e70f0 in realtà non è bloccato da qualsiasi thread. Cosa potrebbe bloccarlo?

In tutta la documentazione di deadlock che ho letto (example), per ogni diversa linea - parking to wait for <0x123>, c'è sempre una riga - locked <0x123>. Quindi comincio a sospettare un bug JVM. Sto fraintendendo qualcosa?

Nota: Ci scusiamo per il collegamento a pastebin, ma la domanda non è risolvibile senza avere il dump completo. Per brevità, ho rimosso tutte le righe che contenevano "at", non includono alcuna informazione di blocco.

fonte

2012-06-28 Nicolas Raoul

Il pacchetto java.util.concurrent utilizza un meccanismo di parcheggio nativo extralinguistico (nonché altri meccanismi nativi, come un confronto e scambio atomico). Si può vedere di cosa sto parlando here.

Il modello si descrivono come di solito si verificano nella discarica filo deriva dal classico linguaggio Java synchronized(lock) { lock.wait(); }. La risposta di

fonte

2012-06-28 07:31:29

Grazie per il collegamento! Ora mi sono reso familiare con la classe Unsafe. Anche se eseguito tramite una chiamata a Unsafe.park, il blocco viene ancora da una chiamata Java, quindi perché la parte 'locked <0x123>' non può essere scritta su quella linea? Gradirei qualsiasi documentazione che parli del particolare problema dell'ID che non è presente. –

Marko Topolnik è corretta.

Per quanto riguarda una soluzione al problema, JProfiler mostrerà un grafico completo di thread e monitor per le situazioni di blocco che coinvolgono blocchi dal pacchetto java.util.concurrent.

Disclaimer: La mia azienda sviluppa JProfiler

fonte

2012-06-28 08:29:33

cose differenti possono deadlock thread Java, monitor, alias la parola chiave sincronizzato, sono una cosa sola.

A lock can be a built-in object monitor, an ownable synchronizer, or the Condition object associated with synchronizers.

Si può anche scavare nelle definizioni di ThreadMXBean.findDeadlockedThreads e ThreadMXBean.findMonitorDeadlockedThreads per ulteriori informazioni.

Per quanto mi riguarda, sono il blocco del monitor e il blocco di java 5.

Nelle discariche di thread, la combinazione waiting to lock <0x123> e locked <0x123> è solo per il blocco del monitor. con Java 5 si ottiene il blocco solo la prima parte. Qualcosa di simile parking to wait for <0x456>. Quindi si cerca qualche 0x456 nel dump del thread, ma non si trova da nessuna parte. Questo è confusionario.

fonte

2012-09-07 05:22:25 lacroix1547

La complessità dell'analisi Thread Dump per questo tipo di deadlock è principalmente dovuta all'utilizzo del pacchetto java.util.concurrent. Questo è stato costruito per allontanarsi dal modo classico e intrusivo di sincronizzare oggetti Java. Questo pacchetto è molto utile quando, per esempio, si desidera limitare le operazioni WRITE a un singolo modello di Thread mentre si consentono operazioni di READ simultanee. Questo approccio è ottimo da una prospettiva di ottimizzazione delle prestazioni, l'effetto collaterale è un aumento del livello di complessità del processo di analisi di Thread Dump quando si affrontano problemi di concorrenza.

Suggerisco di rivedere anche il seguente articolo. Descrive problemi come gli scenari hidden Java deadlock in cui la JVM non sarà nemmeno in grado di rilevare il deadlock (a causa dei blocchi READ che normalmente non sono progettati per avere una nozione di proprietà). Un esempio di programma Java di esempio.

fonte

2013-08-28 14:09:12

La traccia di stack indica che 0x00002aaaf4394580 non è bloccato da nessun thread. Ciò può verificarsi a causa di Java bug #6822370. Questa osservazione dovrebbe aggiungere la chiusura allo voted answer.

fonte

2014-07-23 16:30:06

"Trovato 1 stallo", ma traccia mostra che non bloccato da qualsiasi thread

risposta

Problemi correlati