Quanto pesano i monitor Java?

Question

Dire che ho una matrice di migliaia di oggetti e un piccolo numero di thread che potrebbero accedere a ciascuno degli oggetti. Voglio proteggere l'accesso a uno dei metodi degli oggetti. Il modo più semplice sarebbe dichiarare tale metodo come synchronized. Tuttavia, ciò potrebbe comportare la creazione di migliaia di monitor, indipendentemente dal modo in cui vengono implementati. Se questo fosse Win32, non creerei mai migliaia di oggetti del kernel come Mutex, ma CRITICAL_SECTIONs potrebbe essere plausibile. Mi chiedo cosa succede in Java. Data la possibilità di contesa è bassa, l'uso di monitor imporrebbe più della quantità di memoria che richiedono? Com'è diffusa la pratica di utilizzare una sincronizzazione a bassa granularità in Java?

(Esistono ovviamente soluzioni alternative come l'utilizzo di una matrice molto più piccola di oggetti di sincronizzazione, a cui si accederà utilizzando un hash .. Non sto cercando una soluzione pratica, sto cercando un approfondimento).

Answer 1

Hai già pagato (la maggior parte e in bassa contesa) la penalità per avere i monitor in giro usando Java ... non ha senso non usarli. In particolare nel caso di bassa controversia, sono molto economici (vedere Items 2.1, 2.2, 2.3 here e Item #1 here) e la JVM può ottimizzarli completamente per un numero di casi. Se si utilizza il monitor dell'oggetto solo transitoriamente, la JVM lo renderà "abbastanza grande" (ovvero inizia come bit-flipping, potrebbe espandersi per casi di contesa semplici su un flag atomico impilato allo stack e in conflitto persistente avere un objectmonitor allocato per esso, tutti questi verranno srotolati al caso di low-overhead mentre la contesa diminuisce) e recupererà lo spazio più tardi. Nella misura in cui il blocco su questi oggetti è la "cosa giusta" dal lato delle applicazioni, direi di provarci.

Tuttavia, c'è un odore di design qui. Bloccare su così tanti oggetti non suona bene. Inoltre, se si dispone di condizioni di blocco sequenziali, non si è in grado di ragionare su potenziali punti di stallo. Ti suggerisco di aumentare la tua domanda con maggiori dettagli sull'applicazione, e possiamo chiederci se il blocco su una grande quantità di oggetti sia la cosa giusta.

Questo presentation by Dave Dice fornisce alcune informazioni utili su come funziona la sincronizzazione Java6 e questo blog entry is a treasure trove of sync-on-Java information. Se davvero, davvero ti interessa di quanto "grande" sia una struttura dimonitor degli oggetti completa (entrerà in gioco nel caso conteso), lo code is here. La pagina wiki di HotSpot internals ha anche qualche good in-depth information.

Answer 2

Penso che Collections.synchronizedCollection consenta a un thread di accedere alla raccolta. Tuttavia esiste il problema della creazione di monitor.

Answer 3

I mutex Java sono abbastanza economici da poter contenere centinaia di migliaia di oggetti sincronizzati e non notarlo.

Nel caso contrario, un mutex Java consiste di soli 2 bit nella parola flags. La JVM associa solo un oggetto di blocco del sistema operativo pesante con un mutex Java quando il mutex è conteso, quindi rilascia il blocco del sistema operativo quando il mutex è stato chiuso da tutti i thread.

Una panoramica di come mutex Java attuazione può essere trovato in vetrini da 9 a 23 di this presentation da JavaOne 2006.

---

nota che l'attuazione e le prestazioni del mutex è tale da dipendere venditore/rilascio di Java che stai utilizzando e la piattaforma su cui stai lavorando.

• Nelle prime versioni di Java, i mutex erano significativamente più costosi.
• Potrebbero esserci stati dei progressi da quando il documento JavaOne 2006 ... è stato pubblicato o meno.