JVM Options

Kita telah melihat JVM dari dalam — heap, stack, Metaspace, collector — kini saatnya memegang panel kendalinya. Seluruh perilaku tersebut dapat diatur dari command line lewat bendera (flags) yang ditempatkan sebelum nama class utama: berapa besar heap, collector mana yang bekerja, seberapa lebar tiap stack, apa yang dicatat ke log. Memahami tata nama bendera adalah keterampilan operasional yang dipakai setiap hari — membaca startup script aplikasi produksi, menyetel container, atau sekadar menjawab “bendera ini artinya apa” saat berdiskusi dengan tim infrastruktur. Pada chapter ini kita susun kamusnya, lalu uji bendera penting satu per satu dengan keluaran nyata.

Tata Nama Bendera -X dan -XX #

Bendera JVM datang dalam dua keluarga besar. Bendera -X adalah bendera standar yang stabil antar versi dan vendor — ukuran memori adalah anggotanya yang paling sering dipakai. Bendera -XX adalah bendera lanjutan milik HotSpot yang bisa Boolean (mengaktifkan/mematikan) atau bernilai. Ringkasannya:

Kaidah penulisannya lugas. Bendera Boolean memakai -XX:+NamaBendera untuk mengaktifkan dan -XX:-NamaBendera untuk mematikan; bendera bernilai memakai -XX:NamaBendera=nilai tanpa tanda sama dengan ganda. Ukuran ditulis dengan akhiran k, m, g — 64m berarti 64 × 1024 × 1024 byte. Salah ketik nama bendera tidak berlalu diam-diam: JVM menolak berjalan sejak baris perintah, sebagaimana kita lihat pada bagian akhir chapter.

Mengatur Heap dengan -Xms dan -Xmx #

-Xmx menetapkan batas atas heap dan -Xms titik awalnya. JVM boleh tumbuh dan menyusut di antara keduanya, jadi jarak Xms-ke-Xmx adalah ruang adaptasi: sempit berarti ukuran stabil tanpa biaya penyesuaian; lebar berarti JVM menyesuaikan beban namun sesekali menegosiasikan ulang memori ke sistem operasi. Jalankan JVM dengan kedua bendera dan cetak bendera akhirnya, hasil pengaturannya terlihat eksplisit:

java -Xms64m -Xmx128m -XX:+PrintCommandLineFlags -version

-XX:InitialHeapSize=67108864 -XX:MaxHeapSize=134217728 -XX:MinHeapSize=67108864 ... -XX:+UseG1GC
openjdk version "25.0.4.1" 2026-08-18 LTS

Angka-angka itu penuh makna: -Xms64m menjadi InitialHeapSize=67108864 — tepat 64 × 1024 × 1024 byte — dan -Xmx128m menjadi MaxHeapSize=134217728 byte. Bendera -X sesungguhnya adalah kependekan yang ramah manusia untuk bendera -XX yang setara; -Xmx hanyalah MaxHeapSize dalam baju lain. Nilai UseG1GC yang tetap aktif menegaskan pemilihan collector tidak berubah oleh pengaturan ukuran. Perlu dicatat, daftar lengkap bendera aktif pada keluaran di atas dipengaruhi ergonomi mesin — pada komputer lain baris itu boleh berisi nilai ergonomis berbeda, namun pemetaan 64m → 67108864 selalu pasti.

Bendera -XX untuk Collector, Metaspace, dan CPU #

Contoh paling instruktif dari bendera bernilai adalah ActiveProcessorCount. Program berikut membaca jumlah prosesor yang terlihat JVM:

public class InfoOpsi {
    public static void main(String[] args) {
        System.out.println("processor terlihat JVM: " + Runtime.getRuntime().availableProcessors());
    }
}

Output yang Dihasilkan:

processor terlihat JVM: 2

Pada mesin uji tanpa bendera, JVM melihat 2 prosesor — angka ini diambil dari mesin dan bisa berbeda di komputer Anda. Bendera ActiveProcessorCount menimpanya tanpa menyentuh perangkat keras:

java -XX:ActiveProcessorCount=4 InfoOpsi.java

processor terlihat JVM: 4

Mengapa ini penting? availableProcessors() menentukan berapa banyak thread GC dan thread compiler yang dibentuk JVM, serta hasil parallelism framework concurrency. Di container, JVM modern membaca batas CPU dari cgroup dan menghitung sendiri; ActiveProcessorCount menjadi katup manual untuk eksperimen dan penyetelan. Pola yang sama berlaku untuk bendera bernilai lain: MaxMetaspaceSize=256m membatasi metadata class sebagaimana dibuktikan Chapter Metaspace, dan -XX:+UseSerialGC mengganti collector bawaan — keluaran -XX:+PrintCommandLineFlags akan menampilkan -XX:+UseSerialGC menggantikan UseG1GC.

Bendera stack -Xss bekerja pada wilayah yang berbeda — lebar lorong frame method per thread. Kita telah menyaksikan di Chapter Heap dan Stack bahwa rekursi tanpa dasar berhenti pada kedalaman yang bergantung ukuran stack: pada mesin uji sekitar 1.700 panggilan dengan -Xss256k, dan hampir 104.000 panggilan dengan -Xss8m. Angka kedalaman pasti berbeda antar mesin dan antar eksekusi, namun hubungan “stack lebih besar menampung rekursi lebih dalam” selalu berlaku.

Log Terpadu dengan -Xlog #

Sejak Java 9, seluruh logging JVM menyatu di bendera -Xlog dengan sintaks tag: -Xlog:gc mengaktifkan log GC pada level info. Chapter Object Lifecycle telah memperlihatkan keluarannya — baris seperti [0.367s][info][gc] GC(0) Pause Young ... yang mencatat setiap koleksi. Tag bisa dirinci: -Xlog:gc* menambahkan detail per fase, -Xlog:gc+heap=debug menggabungkan tag, dan file=nama.log mengarahkan keluaran ke berkas. Level error, warning, info, debug, dan trace mengatur keramaian log — di produksi, info untuk GC sudah sehat.

Diagnostik Saat Terjadi OOM #

Satu bendera diagnostik yang sebaiknya hadir di setiap aplikasi server: -XX:+HeapDumpOnOutOfMemoryError. Saat OutOfMemoryError terjadi, JVM membekukan seluruh heap ke berkas .hprof sebelum aplikasi tidak respons — bahan forensik yang kita bahas pada Chapter Memory Leaks. Pasangannya -XX:HeapDumpPath=/var/dump mengatur lokasi berkas; tanpanya dump ditulis di direktori kerja dengan nama berbasis PID. Kombinasi keduanya mengubah insiden produksi dari tebakan menjadi penyelidikan berbasis bukti.

Terakhir, soal salah ketik: JVM memvalidasi nama bendera saat startup. Menulis -XX:+GunakanG1GC misalnya membatalkan peluncuran seketika dengan pesan Unrecognized VM option 'GunakanG1GC' dan Error: Could not create the Java Virtual Machine — kelakuan yang menolong: bendera typo tidak pernah diam-diam diabaikan. Dengan kamus bendera di tangan, kita siap mengarahkannya ke JVM yang sedang berjalan: Chapter Tools Monitoring JVM memperkenalkan jps, jstat, dan kawan-kawannya untuk mengintip proses hidup tanpa menghentikannya.

Referensi #

• Oracle: java Tool Reference (JDK 25) — semua opsi JVM
• Oracle: Garbage Collection Tuning Guide (JDK 25)
• JEP 158: Unified JVM Logging

public class InfoOpsi {
    public static void main(String[] args) {
        System.out.println("processor terlihat JVM: " + Runtime.getRuntime().availableProcessors());
    }
}