Ehcache berbicara tentang memori on-heap dan off-heap. Apa bedanya? Argumen JVM apa yang digunakan untuk mengkonfigurasinya?
Jawaban:
Toko on-heap merujuk ke objek yang akan hadir di tumpukan Jawa (dan juga tunduk pada GC). Di sisi lain, toko off-heap mengacu pada objek (serial) yang dikelola oleh EHCache, tetapi disimpan di luar heap (dan juga tidak tunduk pada GC). Karena toko off-heap terus dikelola dalam memori, ini sedikit lebih lambat daripada toko on-heap, tetapi masih lebih cepat dari toko disk.
Detail internal yang terlibat dalam manajemen dan penggunaan toko di luar tumpukan tidak begitu jelas dalam tautan yang diposting di pertanyaan, jadi sebaiknya lihat detail Terracotta BigMemory , yang digunakan untuk mengelola off-disk toko. BigMemory (toko off-heap) akan digunakan untuk menghindari overhead GC pada heap yang beberapa Megabytes atau Gigabytes besar. BigMemory menggunakan ruang alamat memori proses JVM, melalui ByteBuffers langsung yang tidak tunduk pada GC tidak seperti objek Java asli lainnya.
dari http://code.google.com/p/fast-serialization/wiki/QuickStartHeapOff
Apa itu Heap-Offloading?
Biasanya semua objek non-temporer yang Anda alokasikan dikelola oleh pengumpul sampah java. Meskipun VM melakukan pekerjaan yang layak melakukan pengumpulan sampah, pada titik tertentu VM harus melakukan apa yang disebut 'GC Penuh'. GC lengkap melibatkan pemindaian Heap yang dialokasikan lengkap, yang berarti GC jeda / perlambatan sebanding dengan ukuran tumpukan aplikasi. Jadi jangan percaya orang mengatakan 'Memory is Cheap'. Dalam konsumsi memori java sakit kinerja. Selain itu, Anda mungkin mendapatkan jeda penting menggunakan ukuran tumpukan> 1 Gb. Ini bisa menjijikkan jika Anda memiliki hal-hal yang hampir real-time terjadi, dalam sebuah cluster atau grid proses java mungkin menjadi tidak responsif dan bisa jatuh dari cluster.
Namun, aplikasi server saat ini (sering dibangun di atas kerangka kerja yang mengasyikkan ;-)) dengan mudah membutuhkan tumpukan jauh melebihi 4Gb.
Salah satu solusi untuk persyaratan memori ini, adalah 'melepas' bagian-bagian objek ke tumpukan non-java (langsung dialokasikan dari OS). Untungnya java.nio menyediakan kelas untuk secara langsung mengalokasikan / membaca dan menulis potongan memori 'tidak dikelola' (bahkan file yang dipetakan memori).
Jadi seseorang dapat mengalokasikan sejumlah besar memori 'tidak terkelola' dan menggunakannya untuk menyimpan objek di sana. Untuk menyimpan objek yang sewenang-wenang ke dalam memori yang tidak dikelola, solusi yang paling memungkinkan adalah penggunaan Serialisasi. Ini berarti aplikasi membuat serialisasi objek ke dalam memori offheap, nanti objek dapat dibaca menggunakan deserialization.
Ukuran heap yang dikelola oleh Java VM bisa dijaga tetap kecil, jadi GC jeda ada di millis, semua orang senang, pekerjaan selesai.
Jelas, bahwa kinerja buffer off-heap seperti itu sebagian besar tergantung pada kinerja implementasi serialisasi. Berita bagus: untuk beberapa alasan FST-serialisasi cukup cepat :-).
Skenario penggunaan sampel:
Sunting: Untuk beberapa skenario, seseorang dapat memilih algoritma Pengumpulan Sampah yang lebih canggih seperti ConcurrentMarkAndSweep atau G1 untuk mendukung tumpukan yang lebih besar (tetapi ini juga memiliki batas melebihi tumpukan 16GB). Ada juga JVM komersial dengan peningkatan 'jeda' GC (Azul) tersedia.
Tumpukan adalah tempat di memori tempat objek Anda yang dialokasikan secara dinamis hidup. Jika Anda menggunakan newmaka ada di tumpukan. Itu berlawanan dengan ruang stack, yang merupakan tempat fungsi stack hidup. Jika Anda memiliki variabel lokal maka referensi itu ada di tumpukan. Tumpukan Jawa tunduk pada pengumpulan sampah dan benda-benda dapat digunakan secara langsung.
Penyimpanan off-heap EHCache menghilangkan objek reguler Anda dari heap, membuat serial, dan menyimpannya sebagai byte di dalam sepotong memori yang dikelola EHCache. Ini seperti menyimpannya ke disk tetapi masih dalam RAM. Objek tidak secara langsung dapat digunakan dalam keadaan ini, mereka harus dideeralisasi terlebih dahulu. Juga tidak dikenakan pengumpulan sampah.
Tidak 100%; Namun, sepertinya heap adalah objek atau set ruang yang dialokasikan (pada RAM) yang dibangun ke dalam fungsi kode baik Java itu sendiri atau fungsionalitas yang lebih mungkin dari ehcache itu sendiri, dan Ram off-heap ada sistem sendiri sebagai baik; namun, sepertinya ini satu kali lebih lambat karena tidak terorganisir, artinya tidak boleh menggunakan heap (artinya satu set panjang ruang ram), dan alih-alih menggunakan ruang alamat yang berbeda yang sepertinya membuatnya sedikit kurang efisien.
Maka tentu saja tingkat berikutnya yang lebih rendah adalah ruang hard-drive itu sendiri.
Saya tidak menggunakan ehcache, jadi Anda mungkin tidak ingin mempercayai saya, tetapi itulah yang saya kumpulkan dari dokumentasi mereka.
