Nah, ada beberapa pertanyaan di sini!
1 - Bagaimana cara mengatur objek berumur pendek?
Seperti yang dinyatakan sebelumnya, JVM dapat dengan sempurna menangani sejumlah besar objek berumur pendek, karena mengikuti Hipotesis Generasi Lemah .
Perhatikan bahwa kita berbicara tentang objek yang mencapai memori utama (heap). Ini tidak selalu terjadi. Banyak objek yang Anda buat bahkan tidak meninggalkan register CPU. Misalnya, pertimbangkan ini untuk loop
for(int i=0, i<max, i++) {
// stuff that implies i
}
Jangan berpikir tentang loop unrolling (optimisasi yang dijalankan JVM pada kode Anda). Jika maxsama dengan Integer.MAX_VALUE, perulangan Anda mungkin memerlukan beberapa waktu untuk dieksekusi. Namun, ivariabel tidak akan pernah lepas dari blok loop. Oleh karena itu, JVM akan meletakkan variabel itu dalam register CPU, menaikkannya secara teratur tetapi tidak akan pernah mengirimnya kembali ke memori utama.
Jadi, membuat jutaan objek bukanlah masalah besar jika hanya digunakan secara lokal. Mereka akan mati sebelum disimpan di Eden, jadi GC tidak akan menyadarinya.
2 - Apakah berguna untuk mengurangi overhead GC?
Seperti biasa, itu tergantung.
Pertama, Anda harus mengaktifkan logging GC agar dapat melihat dengan jelas tentang apa yang sedang terjadi. Anda dapat mengaktifkannya dengan-Xloggc:gc.log -XX:+PrintGCDetails .
Jika aplikasi Anda menghabiskan banyak waktu dalam siklus GC, maka, ya, sesuaikan GC, jika tidak, itu mungkin tidak terlalu berharga.
Misalnya, jika Anda memiliki GC muda setiap 100 md yang membutuhkan 10 md, Anda menghabiskan 10% waktu Anda di GC, dan Anda memiliki 10 koleksi per detik (yang huuuuuge). Dalam kasus seperti itu, saya tidak akan menghabiskan waktu dalam penyetelan GC, karena 10 GC / s itu akan tetap ada.
3 - Beberapa pengalaman
Saya memiliki masalah serupa pada aplikasi yang membuat sejumlah besar kelas tertentu. Di log GC, saya perhatikan bahwa tingkat pembuatan aplikasi sekitar 3 GB / s, yang terlalu banyak (ayolah ... 3 gigabyte data setiap detik?!).
Masalahnya: Terlalu banyak GC yang disebabkan oleh terlalu banyak objek yang dibuat.
Dalam kasus saya, saya memasang profiler memori dan memperhatikan bahwa kelas mewakili persentase besar dari semua objek saya. Saya melacak contoh untuk mengetahui bahwa kelas ini pada dasarnya adalah sepasang boolean yang dibungkus dalam suatu objek. Dalam kasus tersebut, dua solusi tersedia:
Mengolah algoritma sehingga saya tidak mengembalikan sepasang boolean tetapi saya memiliki dua metode yang mengembalikan setiap boolean secara terpisah
Simpan objek dalam cache, dengan mengetahui bahwa hanya ada 4 contoh berbeda
Saya memilih yang kedua, karena berdampak paling kecil pada aplikasi dan mudah diperkenalkan. Butuh beberapa menit untuk menempatkan pabrik dengan cache yang tidak aman untuk thread (saya tidak memerlukan keamanan thread karena pada akhirnya saya hanya akan memiliki 4 contoh berbeda).
Tingkat alokasi turun menjadi 1 GB / dtk, begitu pula frekuensi GC muda (dibagi 3).
Semoga membantu!