Salah Kaprah Tentang Garbage Collection pada JVM

jaya28inside

New member
java.jpg

Kalau saya ingat kembali waktu masih kecil, belum ada orang tua saya yang mengajarkan tentang Garbage Collector, tetapi saya ingat ada petugas pemungut sampah keliling sekitar komplek. Hehe, beneran. Tetapi untuk artikel kali ini saya akan memaprkan tentang Garbage Collector yang dimiliki oleh JVM alias Java.
Anda mungkin pernah memiliki faham seperti ini:

1) Hanya ada satu Garbage Collector.

Ngga deh, ngga bukan cuma itu. Dalam Hotspot JVM ada 4 garbage collector: Serial, Parallel / Throughput, CMS dan block G1. Tetapi itu baru sebagian, ada bagian lain yang non-standard Garbage Collector dan lebih menantang ketika diimplementasikan nantinya seperti Shenandoah atau Collector lain yang digunakan oleh JVM (C4, dibuat oleh Azul). Pada Hotspot secara default digunakan Parallel / Throughput collector tetapi sayangnya tidak semua aplikasi java cocok pakai ini. Misalnya, CMS dan G1 collector akan menyebabkan GC lebih sering tersendat2 (agak lambat). Tetapi ketika memang disengaja untuk di-pause, maka durasinya bisa jadi lebih lama dari Parallel Collector. Konsekuensinya jika digunakan Parallel Collector, maka throughput dengan heap yang sama ukurannya akan menjadi lebih tinggi.

Solusinya? Pilih Garbage Collector yang diperlukan aplikasi anda. Misalnya GC disesuaikan dengan nilai pause & durationnya.


2. Parallel = Concurrent.

Whahaha, sebenarnya pada perputaran Garbage Collection bisa menyebabkan GC berhenti, atau bisa juga tuntas (beres) secara aman tanpa menghentikan aplikasi yang sedang berjalan. Kalau ditelaah lebih dalam, GC Algorithm bisa menjadi serial (single thread) atau parallel (multi-threaded). Ketika itulah concurrent GC dipakai, tetapi tidak selalu bermakna digunakan secara palalel. Dan ingat ketika digunakan serial GC tidak selalu berarti menyebabkan pause (berhenti). Dalam dunia Garbage Collection, istilah Concurrent dan Parallel itu dua hal yang berbeda dimana Concurrent mengacu ke perputaran GC , dan Parallel mengacu ke Algorithma GC itu tadi.

Solusi: Garbage Collection sebenarnya terkandung 2 hal, cara menyertakan perputaran GC, dan cara menuntaskannya. Dua hal ini perlu difahami baik2.


3. G1 menuntaskan seluruhnya

Pada Java 7 dengan beberapa updates yg ada, G1 collector ialah versi terbaru dalam JVM Garbage Collector. Keuntungannya ialah dengan G1 maka problem fragmentasi bisa terselesaikan dengan baik dengan bantuan CMS collector. Seperti apakah itu? Perputaran GC melepaskan sejumlah memory dari tempat lama, lalu memberikan tempat baru yang JVM tak bisa selesaikan. Collector lainnaya bisa melakukan G1 dengan kasus tertentu. Tergantung apa requirement anda.

Solusi: Tidak ada simsalabim yang dilakukan untuk setiap problem GC. Harus ada percobaan tertentu untuk memastikan mana yang sesuai kepada JVM anda.


4. GC Log menyebabkan kelambatan.

Bener-bener dusta ini. Apalagi kalau default log yang digunakan. pada Java 7 sudah dijelaskan adanya hook untuk mengatur ukuran log ini sehingga tidak akan memakan seluruh isi harddisk. Jika anda tidak memperhatikan GC log maka anda kehilangan produktifitas pada setiap kali aktifitas JVM dengan GCnya. Yang ada juga 5% overhead GC yang diperbolehkan terjadi, dan biasanya tidak terasa oleh System.

Solusi: Gunakan data yang anda butuhkan.

Dan... sekian aja dulu deh seputar GC-nya. Lain kesempatan kita sambung kembali.

Artikel asli.

 
Back
Top