Temu duga konkurensi Java: bilakah virtual thread membantu, dan bilakah ia gagal?

Gesaan dan konteks

Soalan pengekodan dan konkurensi ini sesuai untuk peranan backend, platform dan prestasi Java. Ia meminta anda membandingkan platform thread, virtual thread dan panggilan balik tak segerak (asynchronous callbacks) sambil menilai konkurensi, CPU, I/O menyekat, pool hiliran dan diagnostik secara bersama. Peraturan keputusan yang boleh diguna semula lebih penting daripada menghafal nama API.

Perkara yang dinilai oleh penemu duga

• Sama ada anda menerangkan bahawa virtual thread meningkatkan konkurensi berskala dan daya pemprosesan (throughput), bukan kelajuan pelaksanaan tugas tunggal.
• Sama ada anda mengenal pasti pinning daripada synchronized atau panggilan natif serta had yang dikenakan oleh kerja terikat CPU (CPU-bound).
• Sama ada anda menyatakan fan-out dengan satu virtual thread bagi setiap tugas dan mengehadkan sumber hiliran yang terhad dengan semafor atau pool.
• Sama ada anda mereka bentuk pengesahan menggunakan JFR, thread dump, kependaman (latency), penggunaan carrier dan masa menunggu hiliran.

Soalan penjelasan sebelum menjawab

Tanya sama ada permintaan kebanyakannya menunggu rangkaian, pangkalan data atau kerja CPU; sama ada ketiga-tiga panggilan boleh dijalankan secara selari; dan had konkurensi serta sambungan yang dikenakan oleh perkhidmatan hiliran. Sahkan sama ada rangka kerja dan pemacu menyokong API menyekat, sama ada seksyen synchronized atau natif yang panjang wujud, sama ada sasaran adalah p99 yang lebih rendah atau throughput yang lebih tinggi, dan sama ada pelaksana (executor) lama boleh dikekalkan semasa canary.

Rangka kerja jawapan 30 saat

Virtual thread mengekalkan kod I/O menyekat yang mudah dan melepaskan carrier semasa menunggu, jadi ia sesuai untuk permintaan yang menggunakan I/O secara intensif. Ia tidak mempercepatkan kod CPU atau mencipta sambungan pangkalan data atau kuota hiliran. Saya akan menggunakan satu virtual thread bagi setiap tugas fan-out, semafor atau pool sambungan untuk sumber yang terhad, dan memeriksa kunci serta panggilan natif untuk mencari pinning. Saya akan membuktikan migrasi dengan JFR, thread dump, masa menunggu hiliran dan perbandingan p99/throughput dan bukannya menganggap bahawa penggantian pool adalah lebih pantas.

Penyelesaian langkah demi langkah

1. Takrifkan faedah sebagai konkurensi semasa menunggu

Platform thread kekal terikat pada OS thread semasa menunggu I/O; virtual thread boleh digantung semasa I/O menyekat manakala carrier-nya menjalankan virtual thread lain. Ini sesuai untuk perkhidmatan yang permintaannya menghabiskan sebahagian besar masa menunggu pada rangkaian atau pangkalan data. Kod terikat CPU masih tertakluk pada had teras dan penjadual; virtual thread tidak mengurangkan kerumitan algoritma atau masa CPU bagi setiap permintaan.

2. Cipta satu virtual thread bagi setiap tugas, bukan pool virtual thread

Virtual thread ialah representasi tugas yang ringan. Gunakan Executors.newVirtualThreadPerTaskExecutor() untuk mencipta satu bagi setiap tugas yang diserahkan. Pool virtual thread yang bersaiz tetap akan memperkenalkan semula barisan giliran tanpa menggunakan semula carrier yang terhad; hadkan sumber luaran dan bukannya mengumpulkan virtual thread dalam pool.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
  Future<Profile> profile = executor.submit(() -> profileClient.fetch(id));
  Future<Orders> orders = executor.submit(() -> orderClient.fetch(id));
  Future<Quota> quota = executor.submit(() -> quotaClient.fetch(id));
  return merge(profile.get(), orders.get(), quota.get());
}

3. Hadkan konkurensi hiliran dengan isyarat khusus

Virtual thread boleh menjadi banyak, tetapi sambungan pangkalan data, QPS penyedia dan deskriptor fail kekal terhad. Lindungi panggilan yang terhad dengan Semaphore, atau bergantung pada pool pangkalan data sedia ada sebagai sempadan konkurensi; jangan jadikan saiz thread pool tetap memikul kedua-dua penggunaan semula thread dan pengehadan sumber. Lepaskan permit dalam finally, dengan polisi had masa (deadline) dan pembatalan untuk menunggu.

4. Kenal pasti pinning dan kerja yang tidak boleh dinyahlekap (non-unmountable)

Virtual thread mungkin kekal dilekapkan pada carrier-nya semasa menyekat di dalam synchronized atau panggilan natif/asing. Kunci dalam memori yang pendek biasanya tidak mendatangkan masalah; kunci I/O yang panjang memegang carrier dan mengurangkan throughput. Gantikan monitor di sekitar kerja menyekat dalam laluan kritikal dengan ReentrantLock yang sesuai, berpandukan peristiwa pinning JFR atau diagnostik dan bukannya penggantian menyeluruh bagi setiap blok synchronized.

5. Kendalikan pembatalan, had masa dan perambatan ralat

Ketiga-tiga panggilan fan-out memerlukan satu had masa permintaan. Apabila panggilan kritikal gagal, batalkan kerja yang masih menunggu supaya kapasiti hiliran tidak digunakan selepas klien mengalami masa tamat (timeout). Virtual thread mengubah pemilikan thread; ia tidak membatalkan Future secara automatik, menutup badan respons atau melepaskan sambungan. Petakan gangguan, masa tamat dan kegagalan hiliran kepada jalan keluar (fallback) eksplisit dan bersihkan sumber dalam finally.

6. Buktikan hasil dengan metrik dan kumpulan kawalan

Bandingkan trafik yang sama pada throughput, p50/p99, CPU, keselarilasan carrier, bilangan virtual thread, menunggu pool sambungan, menunggu semafor dan ralat. Rekodkan jdk.VirtualThreadPinned dan peristiwa mula/tamat dengan JFR; periksa tindanan dengan thread dump jcmd. Jalankan beban kerja berasingan bagi menunggu I/O, terikat CPU, kadar hiliran terhad dan perebutan kunci. Peningkatan dalam kes I/O tetapi bukan kes CPU adalah hasil yang dijangkakan.

Contoh jawapan berkualiti tinggi

Saya tidak akan menganggap virtual thread sebagai thread pool yang lebih pantas. Ia sesuai untuk perkhidmatan yang permintaannya menghabiskan sebahagian besar masa dalam I/O menyekat kerana virtual thread boleh menggantung dan melepaskan carrier-nya; kerja terikat CPU masih tertakluk pada had teras. Bagi tiga panggilan hiliran selari, saya akan menggunakan pelaksana virtual thread bagi setiap tugas dengan satu had masa permintaan dan pembatalan; pool sambungan atau semafor akan menguatkuasakan had pangkalan data dan penyedia. Saya akan memeriksa pemacu, kunci dan panggilan natif supaya I/O yang lama tidak berada di dalam synchronized dan mem-pin carrier. Percubaan canary akan membandingkan throughput, p99, penggunaan carrier, masa menunggu hiliran, peristiwa pinning JFR dan thread dump sebelum meluaskan migrasi.

Kesilapan lazim

• Menyatakan bahawa virtual thread menjadikan kod CPU lebih pantas → ia terutamanya meningkatkan konkurensi untuk kerja yang menunggu dan tidak menambah teras CPU → ukur throughput, kependaman dan kerja CPU secara berasingan.
• Mencipta pool virtual thread yang tetap → ia mengelirukan pengumpulan thread dengan pengehadan sumber → cipta satu virtual thread bagi setiap tugas dan gunakan semafor atau pool di hiliran.
• Menggantikan setiap blok synchronized → seksyen kritikal memori yang pendek tidak semestinya berbahaya, dan penggantian membuta tuli menambah kerumitan → ubah laluan kunci menyekat yang disokong oleh bukti JFR.
• Mengabaikan had sambungan hiliran → lebih banyak virtual thread tidak mencipta sambungan atau kuota → takrifkan belanjawan, had masa dan tingkah laku fallback.
• Hanya menjalankan ujian beban konkurensi tinggi → pinning, kebocoran pembatalan atau ketepuan CPU mungkin kekal tersembunyi → uji I/O, CPU, kunci, had dan pemulihan secara berasingan.

Soalan susulan dan respons

Apakah pertukaran (trade-off) antara virtual thread dan pengaturcaraan reaktif?

Virtual thread mengekalkan kod menyekat imperatif dan diagnostik yang biasa, yang sesuai dengan perkhidmatan yang menggunakan I/O secara intensif yang memerlukan stack trace yang mudah dibaca. Kod reaktif mungkin sesuai untuk komposisi aliran peristiwa, bilangan sambungan yang sangat tinggi atau ekosistem tanpa sekatan (non-blocking) yang mantap. Pilih berdasarkan sokongan pemacu, kos penyelenggaraan, sasaran kependaman dan kebolehcerapan, bukan daripada andaian bahawa yang lebih baharu bermakna lebih pantas.

Bagaimanakah anda mengehadkan satu penyedia kepada sepuluh panggilan serentak?

Cipta Semaphore dengan sepuluh permit, peroleh sebelum panggilan penyedia, dan lepaskan dalam finally; batasi masa menunggu permit dengan had masa permintaan dan kembalikan fallback atau hasil giliran apabila masa tamat. Jika pool sambungan sedia ada sudah mewakili sempadan sebenar, gunakannya dan bukannya menambah had kedua.

Mengapakah kebuluran carrier (carrier starvation) masih boleh berlaku?

Penyekatan synchronized yang panjang, panggilan natif, tugas berat CPU atau menunggu luaran tanpa batasan boleh memegang carrier atau menghabiskan keselarilasan. Periksa peristiwa pinning JFR, thread dump, profil CPU dan masa menunggu hiliran untuk membezakan pinning daripada barisan giliran biasa.

Bolehkah virtual thread menggantikan pool sambungan pangkalan data?

Tidak. Virtual thread membawa tugas; sambungan pangkalan data adalah sumber luaran yang terhad. Kekalkan pool, had masa, sempadan transaksi dan metrik menunggu pool. Membiarkan virtual thread tanpa had menunggu sambungan hanya memindahkan tekanan ke dalam memori dan had masa permintaan.

Bagaimanakah anda membuktikan bahawa migrasi tidak memburukkan lagi kependaman?

Kekalkan input, taburan respons hiliran dan kadar ralat secara malar. Bandingkan canary lama dan canary virtual-thread pada p50/p99, throughput, CPU, penggunaan carrier, masa menunggu pool, penyelesaian pembatalan dan peristiwa pinning. Sertakan kes keadaan stabil, lonjakan tiba-tiba, hiliran perlahan, kehabisan pool dan mulakan semula, dengan ambang undur balik (rollback) sebelum meluaskan trafik.