Dimensioni heap iniziali e massime

La comprensione delle operazioni del GC (Garbage Collector) consente di impostare le dimensioni heap iniziali e massime per una gestione efficiente dell'heap.

Il raccoglitore dati inutilizzati adatta la dimensione heap per mantenere l'occupazione tra il 40% e il 70% per i seguenti motivi:
  • Un'occupazione heap superiore al 70% causa cicli GC più frequenti, che possono ridurre le prestazioni. È possibile modificare questo comportamento impostando l'opzione -Xminf .
  • Un'occupazione heap inferiore al 40% indica cicli GC non frequenti. Tuttavia, questi cicli sono più lunghi del necessario, causando tempi di pausa più lunghi, che possono ridurre le prestazioni. È possibile modificare questo comportamento impostando l'opzione -Xmaxf .
Se non si imposta una dimensione heap iniziale o massima, la raccolta dati inutilizzati espande e riduce l'heap come richiesto. Tuttavia, se si fissa la dimensione heap utilizzando le opzioni -Xms e -Xmx , la raccolta dati inutilizzati non espande o riduce l'heap Java™ . Per ottimizzare le prestazioni dell'applicazione e mantenere l'intervallo compreso tra il 40 e il 70%, l'impostazione della dimensione heap massima deve essere superiore di almeno il 43% rispetto all'occupazione massima dell'applicazione. Ad esempio, se un'applicazione ha una capacità massima di 70 MB, è necessario impostare una dimensione heap massima di 100 MB, come mostrato nel seguente calcolo:
70 + (70 * 43/100)

L'impostazione della dimensione heap minima e massima sullo stesso valore non è generalmente una buona idea poiché la raccolta dati inutilizzati viene ritardata fino a quando l'heap non è pieno. Pertanto, la prima volta che viene eseguito il GC, il processo può richiedere più tempo. Inoltre, è più probabile che l'heap sia frammentato e richieda una compattazione dell'heap. Avviare l'applicazione con la dimensione heap minima richiesta dall'applicazione. Quando la raccolta dati inutilizzati viene avviata, viene eseguita frequentemente ed in modo efficiente perché l'heap è piccolo.

Se la raccolta dati inutilizzati non riesce a trovare un numero sufficiente di dati inutilizzati, esegue la compattazione. Se la raccolta dati inutilizzati trova un numero sufficiente di dati inutilizzati o se viene soddisfatta una delle altre condizioni per l'espansione heap (consultare Assegnazione heap nella documentazione utenteOpenJ9), la raccolta dati inutilizzati espande l'heap.

Pertanto, un'applicazione generalmente viene eseguita fino a quando l'heap non è pieno. Quindi, i cicli di raccolta dati inutilizzati successivi recuperano i dati inutilizzati. Quando l'heap è pieno di oggetti attivi, GC compatta l'heap. Se non viene ancora ripristinato un numero sufficiente di dati inutilizzati, la raccolta dati inutilizzati espande l'heap.

Dalla descrizione precedente, è possibile vedere che la raccolta dati inutilizzati compatta l'heap in base alle necessità dell'applicazione, in modo che quando l'heap si espande, si espande con una serie di oggetti compattati nella parte inferiore dell'heap originale. Questo processo è un modo efficiente per gestire l'heap poiché la compattazione viene eseguita sulla dimensione heap più piccola possibile nel momento in cui viene rilevata la necessità della compattazione. La compattazione viene eseguita con le dimensioni heap minime man mano che l'heap aumenta. Esistono alcune prove che la serie iniziale di oggetti di un'applicazione tende ad essere la serie di chiavi o root, in modo che la loro compressione liberi il resto dell'heap per gli oggetti di breve durata.

Alla fine, la JVM ha l'heap alla dimensione massima con tutti gli oggetti di lunga durata compattati nella parte inferiore dell'heap. La compattazione si è verificata quando la compattazione era nella fase meno costosa. La quantità di elaborazione e di utilizzo della memoria richiesta per espandere l'heap è quasi banale rispetto al costo della raccolta e della compressione di un heap frammentato molto grande.