Seberapa aman untuk melakukan peningkatan JVM kecil?


10

Saya telah bekerja di JVM selama bertahun-tahun dan saya sangat jarang mengalami crash JVM ... yaitu sekitar 6 bulan yang lalu.

Sejak itu saya telah mengalami sekitar 5 crash JVM yang dihasilkan dari 2 cacat JVM. Solusi dari Oracle selalu sama ... upgrade.

Setiap peningkatan selalu ke dan dari titik rilis ... yaitu dan saran terbaru Oracle (setelah mengkonfirmasi bahwa mereka memang memperbaiki bug) adalah untuk meningkatkan dari 1,6u20 ke 1,6u26.

Seberapa peduli saya harus meningkatkan versi minor JVM?

Apakah ini peristiwa besar yang memerlukan pengujian regresi dalam jumlah besar atau apakah itu peningkatan yang aman yang harus direngkuh?


3
Dalam konteks apa JVM tersebut akan berjalan? Apakah Anda menggunakannya untuk bermain applet game atau menjalankan sistem informasi rumah sakit? Jawaban yang benar sangat tergantung pada informasi itu.
blubb

Jawaban:


5

Ini tidak harus menjadi acara besar untuk meng-upgrade versi minor, dan aku tidak pernah masalah berpengalaman.

Yang mengatakan, masalah Java 7 yang terkenal agak menakutkan, dan bahkan sulit itu adalah upgrade versi utama, masalah-masalah khusus itu sebenarnya muncul di Java 6 ~ u20 dan mungkin diperbaiki di u25. Mereka muncul hanya karena Java 7 memiliki beberapa flag optimasi yang diaktifkan secara default sedangkan Java 6 belum. Seandainya Anda menggunakan flag-flag itu di Java 6, Anda bisa saja mengalami tidak hanya crash, tetapi eksekusi loop yang salah, yaitu kesalahan perhitungan, karena upgrade minor dari 6u19 ke 6u20 (kurang-lebih).

Faktanya adalah, tidak ada yang menjamin bahwa versi yang ditingkatkan akan bekerja sama sekali. JVM, lingkungannya (komputer, OS), dan aplikasi Anda, semuanya berinteraksi satu sama lain, dan untuk memastikan bahwa seluruh tumpukan barang bekerja dengan baik, Anda memang harus melakukan sejumlah besar pengujian regresi.

Pendekatan saya terhadap peningkatan JVM mirip dengan peningkatan apa pun: kecuali jika saya memiliki kebutuhan khusus untuk meningkatkan dan kecuali itu merupakan peningkatan keamanan yang kritis, saya akan menunggu sebentar dan membaca pengalaman orang lain di internet. Jika tidak ada yang mengeluh dalam sebulan atau lebih, maka kemungkinan besar aman untuk ditingkatkan.


Apakah ada tempat khusus yang Anda lihat untuk membaca pengalaman orang lain di internet?
Dakotah North

@Dakotah North: Bukan tempat tertentu. Tergantung pada banyak milis (seperti announce@apache.org , di mana peringatan masalah kritis datang pada hari Java 7 dirilis) memberikan banyak informasi semacam ini.
Joonas Pulakka

4

Dalam pengalaman saya dengan aplikasi Java perusahaan, manfaat merangkul pembaruan JVM kecil menghadapi risiko yang terkait.

Satu manfaat adalah bahwa pembaruan kecil hampir selalu berisi perbaikan bug . Menerapkan pembaruan ini sebenarnya dapat meningkatkan stabilitas lingkungan produksi Anda. Saya telah mengalami crash JVM di mana analisis akar penyebab mengungkapkan bahwa cacat telah diidentifikasi dan diperbaiki dalam pembaruan JVM kecil.

Manfaat lain adalah pembaruan kecil sering kali berisi peningkatan kinerja . Namun, seperti dicatat oleh @Joonas, berisiko menggunakan bendera kinerja yang tidak terbukti atau eksperimental dalam pembaruan apa pun (besar atau kecil) tanpa pengujian signifikan.

Seperti halnya perubahan apa pun, yang terpenting adalah Anda melanjutkan secara bertanggung jawab . Berikut adalah beberapa praktik yang saya ikuti saat merencanakan pembaruan JVM:

  • Tinjau dengan hati-hati semua catatan rilis untuk setiap pembaruan kecil antara versi Anda saat ini dan versi target.
  • Pahami toleransi pengguna Anda untuk pemadaman aplikasi, dan uji regresi yang sesuai. (@Simon)
  • Teliti pengalaman orang lain di Internet (@Joonas)
  • Siapkan paket rollback (@Thorbjorn)

2

Di sekitar Oracle Java 1.6 u20, pemeriksaan keamanan untuk "kode campuran" diperkenalkan, yang memengaruhi aplikasi kami untuk beberapa pengguna yang menyebabkannya mogok. Ini adalah peningkatan kecil, dan memiliki pengaruh besar dalam produksi.

Selalu siap untuk rollback.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.