Perché / come utilizza Java un meccanismo controllato per mettere in pausa i thread per GC?

Question

Perché / come utilizza Java un meccanismo controllato per mettere in pausa i thread per GC?

#1 da (1 voti)

0

So che Java utilizza un meccanismo controllato per consentire ai thread di essere messi in pausa. Se ho capito bene, hanno messo una lettura da una pagina protetta alla fine di es. loop e cambia la protezione di quella pagina se vogliono che il thread sia messo in pausa.

Quello che non capisco è perché questo è necessario e se questo può anche funzionare. L'unica ragione per cui posso pensare di renderlo necessario è che non devi avere tutti i puntatori nell'heap e puoi anche averli semplicemente nei registri. Tuttavia, se utilizzassi il TSS, non avresti gli stessi dati?

Tuttavia, quello che trovo più interessante è il modo in cui gestiscono le chiamate di sistema. Cosa succede quando il thread sta eseguendo una lettura lenta di un file oltre, ad es. una rete? Il modo GC? Il GC rinuncia a una corsa e riprova un attimo dopo? Cosa succede quando la chiamata di sistema richiede molto tempo?

java garbage-collection

posta Pieter van Ginkel 13.06.2014 - 19:18

fonte

1 risposta

Leggi altre domande sui tag java garbage-collection

Accesso all'attributo struct: casting vs nome del campo Quali sono i motivi per eseguire un WebService da SQL?

score 1 · Answer 1

Se non metti in pausa il mondo, il grafico dell'oggetto può essere modificato contemporaneamente al lavoro del GC. Vengono aggiunti nuovi oggetti, i riferimenti esistenti vengono riscritti sotto i piedi, gli oggetti già contrassegnati diventano irraggiungibili e non tutte queste modifiche potrebbero essere visibili al GC contemporaneamente o nello stesso ordine. Ad esempio, considera questo codice:

Object b = new Something();
// Now the GC reaches obj and scans its fields.
obj.next = b;
b = obj;
// Now the GC decides to scan the stack of this thread.
// It finds that b refers to an object it has already seen,
// so the new Something() is never marked and wrongly GC'd.

Come quasi ogni problema di concorrenza, risolverlo correttamente è piuttosto complicato e ha molte potenzialità per errori sottili e difficili da trovare. Ci sono algoritmi che possono farlo, e sono usati in alcune macchine virtuali avanzate, ma sono molto più complicate e di solito hanno un throughput inferiore. È molto più semplice utilizzare la sincronizzazione più grossolana disponibile.