2009-11-26 6 views
13

Abbiamo un'applicazione Windows Form che utilizza un controllo ActiveX (di terze parti) e si accorgono degli oggetti delle prestazioni .NET in "Memoria CLR .NET" che il il numero di "Sync Blocks" in uso è in costante aumento (insieme all'aumento dell'utilizzo della memoria), anche se la nostra applicazione è inutilizzata.Che cos'è un "blocco di sincronizzazione" e suggerimenti per ridurre il conteggio

La spiegazione incorporato per gli stati di conteggio blocco dissipatore:

Questo contatore visualizza il numero corrente di blocchi di sincronizzazione in uso. I blocchi di sincronizzazione sono strutture di dati per oggetto allocate per la memorizzazione delle informazioni di sincronizzazione. I blocchi di sincronizzazione contengono riferimenti deboli agli oggetti gestiti e devono essere sottoposti a scansione da Garbage Collector. I blocchi di sincronizzazione non si limitano alla memorizzazione delle informazioni di sincronizzazione e possono anche archiviare i metadati di interoperabilità COM. Questo contatore è stato progettato per indicare problemi di prestazioni con l'uso intenso di primitive di sincronizzazione.

Sembra che il conteggio dei blocchi di sincronizzazione venga ripristinato quando si passa a un'applicazione diversa. Che cosa esattamente provoca la creazione di questi e ci sono suggerimenti per ridurne il numero?

(a proposito, in realtà è scritto "blocco di affondare" nella lista dei contatori delle prestazioni. Non sono sicuro se un errore di battitura o uno scherzo idraulico)

+0

Meglio chiamarli blocchi di sincronizzazione, sicuramente nel titolo. –

risposta

19

Ogni volta che si utilizza un primitivo tale blocco come lock o Monitor.Enter nella piattaforma .NET, una struttura di blocco di sincronizzazione viene inizializzata sull'istanza dell'oggetto da bloccare. Come indicato nella definizione, questi blocchi possono contenere più informazioni come il codice hash dell'oggetto e le informazioni di interoperabilità COM.

Poiché questi blocchi sono limitati in ciò che può essere memorizzato, l'accesso simultaneo ai blocchi causa contesa che a sua volta fa sì che il contenuto dell'intestazione dell'oggetto diventi un indice in una tabella di blocchi di sincronizzazione a livello di sistema gestiti dal CLR. Il CLR è in grado di riciclare questi blocchi di sincronizzazione quando e quando l'oggetto ne ha bisogno.

Il blocco su un oggetto comporta sempre la rotazione della CPU prima di attendere su un oggetto kernel di sistema. Ogni volta che lo spin della CPU allocata non viene soddisfatto per consentire ad un monitor di acquisire il blocco della sezione critica, verrà creato un handle di evento di reimpostazione automatica del sistema e un riferimento ad esso verrà inserito nel blocco di sincronizzazione associato. Gli altri thread che attendono questo handle di evento verranno quindi bloccati sull'handle dell'evento finché il thread proprietario non avrà attivato la versione del gestore eventi.

Pertanto, se questo contatore aumenta costantemente, è un segno che troppi thread sono in conflitto per un blocco su uno o più oggetti e questi blocchi potrebbero non essere mai rilasciati.

+0

Potrebbe anche essere rilevante menzionare che la chiamata a GetHashCode() inizializza anche il blocco di sincronizzazione. –

+0

@VincePanuccio Credo che fosse una cosa di .NET 1.1? (Cioè, il CLR lo fa oggi?) – user2864740

Problemi correlati