Wawancara Coding: Bagaimana Anda merancang lazy initialization satu kali yang aman dengan Java 25 StableValue?

Petunjuk dan use case

Anda mengelola layanan dengan konkurensi tinggi yang harus membuat objek konfigurasi yang berat secara lazy dan memublikasikan hasil yang berhasil hanya satu kali. Gunakan Java 25 StableValue dan jelaskan konkurensi, kegagalan, observabilitas, peluncuran fitur preview, dan batas rollback. Petunjuk ini menguji konkurensi Java, penalaran publikasi JMM, dan penilaian mengenai API JDK modern.

Apa yang sedang diuji oleh pewawancara

Apakah Anda mengidentifikasi StableValue dengan benar sebagai preview API Java SE 25 dan bukan sebagai kontrak jangka panjang yang stabil.
Apakah Anda membedakan kontainer write-once dari objek yang immutable.
Apakah Anda dapat menjelaskan perilaku kegagalan dan retry untuk orElseSet, trySet, setOrThrow, dan orElseThrow.
Apakah Anda menangani exception inisialisasi, penginisialisasi yang bersaing, shutdown, dan upgrade.

Pertanyaan untuk diklarifikasi sebelum menjawab

Setelah inisialisasi gagal, bolehkah sistem mencoba lagi, atau apakah kegagalan pertama langsung memicu circuit breaker?
Apakah proses konstruksi memiliki efek samping, dan apakah pemanggil yang bersaing harus menunggu satu hasil bersama?
Bisakah runtime target mengaktifkan fitur preview, dan apakah kebijakan rilis mengizinkan API preview?
Apakah objek tersebut benar-benar immutable, atau apakah memerlukan enkapsulasi dan manajemen siklus hidup tambahan?

Kerangka jawaban 30 detik

Saya akan memperlakukan StableValue sebagai kontainer yang dapat disetel dengan sukses paling banyak satu kali, bukan sebagai jaminan thread-safety otomatis untuk objek di dalamnya. Saya akan mengonstruksi dan memvalidasi nilai sepenuhnya, lalu memublikasikannya dengan orElseSet; pembaca yang bersaing akan mengonsumsi nilai yang dipublikasikan. Jika kegagalan dapat dicoba lagi, saya akan menentukan batas retry, kelas exception, dan pembersihan efek samping. Jika kegagalan bersifat terminal, saya akan menggunakan setOrThrow dengan validasi saat startup. Karena JDK 25 masih menandai API ini sebagai preview, rencana peluncuran harus mencakup flag pengaktifan, pemantauan, rollback, dan pengujian upgrade.

Pembahasan mendalam langkah demi langkah

1. Kontrak StableValue

StableValue menyimpan satu nilai non-null dan memungkinkannya disetel dengan sukses paling banyak satu kali. Fitur ini menawarkan operasi pembacaan, coba-setel (try-set), dan penyetelan yang melempar exception sehingga runtime dapat mengenali nilai yang stabil dan mengoptimalkan publikasi yang aman.

2. Perbedaan dari volatile dan AtomicReference

volatile mengizinkan penulisan berulang, dan AtomicReference mendukung pembaruan serta compare-and-set. StableValue secara langsung mengekspresikan "tidak pernah berubah setelah berhasil disetel." Ini cocok untuk konfigurasi satu kali, hasil yang diparsing, atau handle bersama, bukan cache yang dapat diperbarui atau diganti.

3. Kode lazy initialization satu kali

java

import java.lang.StableValue;

final class CatalogHolder {
    private final StableValue<Catalog> catalog = StableValue.of();

    Catalog get() {
        return catalog.orElseSet(this::loadCatalog);
    }

    private Catalog loadCatalog() {
        return Catalog.loadFrom("/etc/catalog.json");
    }
}

Factory harus menyelesaikan setiap validasi sebelum mengembalikan nilai. Jangan pernah memublikasikan objek yang diinisialisasi sebagian lalu mengubahnya kemudian.

4. Menangani inisialisasi yang bersaing

Ketika beberapa thread memanggil orElseSet, hanya satu nilai yang berhasil dipublikasikan dan yang lainnya harus membaca nilai tersebut. Factory dapat berjalan secara bersamaan, jadi asumsikan bahwa ia dapat dieksekusi lebih dari satu kali dan hindari efek samping yang tidak dapat diubah seperti pendaftaran ganda, penagihan, atau pembuatan file.

5. Kebijakan exception dan retry

Jika factory melempar exception, tidak ada nilai yang dipasang dan pemanggilan berikutnya dapat mencoba lagi. Pisahkan kegagalan sementara dari kesalahan konfigurasi deterministik, lalu tetapkan backoff, batas percobaan, dan metrik. Jika retry dilarang, tangkap kegagalan startup dan gunakan setOrThrow atau hentikan proses secara sengaja.

6. Kapan menggunakan trySet dan setOrThrow

trySet melaporkan apakah upaya ini menang, yang cocok untuk kontrol pertikaian (contention) eksplisit. setOrThrow melempar exception saat sudah disetel atau saat nilainya tidak valid, yang cocok untuk jalur startup dengan satu writer yang terjamin. Pembaca dapat menggunakan orElseThrow untuk menyatakan bahwa inisialisasi harus sudah terjadi.

7. Visibilitas publikasi dan status objek

Kontainer menentukan kapan suatu nilai menjadi terlihat; kontainer tidak membuat objek tersebut menjadi thread-safe secara internal. Jaga agar field Catalog tidak berubah setelah konstruksi dengan final field, immutable collection, atau sinkronisasi terkontrol. Jika memiliki resource yang mutable, tentukan protokol penutupan dan akses konkuren.

8. Rekayasa peluncuran API preview

JDK 25 mendokumentasikan StableValue sebagai preview. Kompilasi dan eksekusi memerlukan opsi preview yang cocok, dijaga agar konsisten di seluruh CI, image kontainer, IDE, dan skrip produksi. Catat implementasi fallback, matriks kompatibilitas, dan langkah-langkah rollback upgrade sebelum mengekspos API preview pada batas yang tidak dapat diubah.

Trade-off dan batasan

Gunakan cache atau referensi atomik saat nilai harus diperbarui, diganti, atau di-evict; StableValue tidak memiliki operasi siklus hidup seperti itu.
Jika factory memiliki efek samping eksternal, pemanggilan yang bersaing dapat mengulanginya. Jadikan operasi tersebut idempoten atau koordinasikan dengan lock terpisah sebelum memublikasikan.
Jika pemanggil harus menunggu inisialisasi, gunakan Future pada lapisan yang lebih tinggi; jangan berasumsi bahwa StableValue menyediakan koordinasi pemblokiran.
Klaim performa preview memerlukan benchmark yang mencakup cold start, contention, exception, dan GC.

Rencana implementasi dan bukti

Kompilasi implementasi minimal dengan preview JDK 25 diaktifkan dan verifikasi nilai kembalian serta exception dari orElseSet, trySet, dan setOrThrow.
Jalankan uji stres konkurensi yang mengukur pemanggilan factory, publikasi yang berhasil, efek samping duplikat, dan latensi pembacaan.
Injeksikan exception konstruksi dan timeout untuk memverifikasi perilaku retry, backoff, peringatan, dan penghentian proses.
Validasi flag startup, JDK kontainer, pemantauan, dan skrip rollback di runtime target.
Gunakan API Oracle, catatan migrasi JDK 25, dan spesifikasi JVM sebagai bukti tinjauan.

Kesalahan umum dan pertanyaan lanjutan

Kesalahan 1: Menyebut StableValue sebagai objek immutable

Ini hanya membatasi penulisan yang berhasil ke kontainer; ini tidak membekukan objek di dalamnya. Nyatakan desain immutability objek itu sendiri.

Kesalahan 2: Mengasumsikan factory hanya berjalan satu kali

Contention atau retry yang gagal dapat mengeksekusinya beberapa kali. Jelaskan efek samping yang idempoten dan verifikasi jumlah pemanggilan.

Kesalahan 3: Mengabaikan pengaktifan preview

Mengompilasi secara lokal di JDK 25 tidak membuktikan kesiapan produksi. Periksa flag preview dalam kompilasi, startup, kontainer, dan CI.

Pertanyaan lanjutan: Mengapa tidak mempertahankan volatile double-checked locking?

Volatile tetap cocok untuk referensi yang dapat diperbarui. Untuk publikasi satu kali yang eksplisit, StableValue mengomunikasikan niat dengan lebih baik, tetapi risiko preview harus diterima dan manfaat apa pun harus dibuktikan dengan benchmark.

Pertanyaan lanjutan: Bagaimana Anda membuktikan tidak adanya efek samping duplikat?

Tambahkan counter yang dapat diamati dan kunci idempotensi ke factory, lalu verifikasi hitungan, resource handle, dan konsistensi nilai akhir di bawah kondisi contention, exception, dan retry.