Projek Loom mengurangkan keperluan untuk pengaturcaraan reaktif dalam banyak kes dengan membuat operasi menyekat murah melalui benang maya, membolehkan kod gaya segerak yang mudah untuk skala dengan cekap. 2. Pengaturcaraan reaktif tetap relevan untuk pengendalian tekanan belakang, aliran data volum tinggi atau tak terhingga, dan komposisi tak segerak yang kompleks. 3. Benang maya cemerlang dalam I/O terikat, menyekat senario dengan kod yang boleh dibaca, sementara corak reaktif masih lebih disukai untuk kawalan halus, pemprosesan aliran, dan persekitaran tanpa tenun. 4. Kedua-duanya boleh wujud bersama, dengan saluran paip reaktif yang berjalan pada benang maya atau menggunakan penjadual yang disokong benang maya, menggabungkan kesederhanaan dan kawalan. 5. Masa depan Java Concurrency nikmat kod menghalang mudah secara lalai, menggunakan pendekatan reaktif hanya apabila keupayaan maju mereka diperlukan, yang bermaksud perpustakaan reaktor seperti Reaktor atau WebFlux tidak usang tetapi harus digunakan dengan bijak.

Pengaturcaraan reaktif di Java secara tradisinya bergantung kepada perpustakaan seperti Reaktor Projek atau RXJava untuk mengendalikan operasi yang tidak segerak, tidak menyekat-terutamanya dalam senario-senario tinggi seperti pelayan web atau sistem yang didorong oleh peristiwa. Walau bagaimanapun, dengan ketibaan Project Loom dan benang maya di Java 21, landskap pengaturcaraan serentak beralih secara dramatik. Ini menimbulkan persoalan penting: Bagaimanakah Projek Loom memberi kesan kepada pengaturcaraan reaktif di Java?

Jawapan ringkas: benang maya mengurangkan keperluan untuk pengaturcaraan reaktif dalam banyak kes penggunaan biasa , tetapi corak reaktif masih mempunyai tempat mereka -terutama ketika berurusan dengan tekanan belakang, aliran data kompleks, atau komposisi berfungsi.

Mari pecahkan ini.

1. Masalah apa yang dilakukan oleh pengaturcaraan reaktif?

Sebelum Loom, mengendalikan beribu -ribu permintaan serentak dengan penghalang tradisional I/O (contohnya, JDBC, Thread.sleep() , atau menyekat panggilan HTTP) adalah mahal. Setiap thread menggunakan memori yang ketara (stack 1MB secara lalai), dan OS mempunyai had pada kiraan thread.

Jadi rangka reaktif seperti Reaktor dan WebFlux muncul:

• Gunakan I/O dan gelung acara yang tidak menyekat (seperti node.js).
• Kongsi sebilangan kecil benang di banyak tugas.
• Proses data sebagai aliran dengan pengendali seperti map , filter , flatMap .
• Sokongan Backpressure -Pengguna dapat mengawal kadar aliran data.

Model ini berfungsi dengan baik tetapi datang dengan kerumitan:

• Lengkung pembelajaran yang curam.
• Debugging yang lebih keras (jejak timbunan mendapat berpecah).
• Interoperability terhad dengan menyekat API.

2. Bagaimana projek tenun mengubah permainan

Projek Loom memperkenalkan benang maya -benang cahaya yang diuruskan oleh JVM, bukan OS.

Faedah Utama:

• Berjuta -juta benang maya boleh berjalan dengan cekap.
• Setiap benang maya menggunakan memori yang jauh lebih rendah (~ beratus -ratus bait).
• Mereka direka untuk menyekat murah . Ya, menyekat sekarang baik -baik saja .

Contoh:

 ExecutOrservice Executor = executors.NewVirtualThreadPerTasKexecutor ();

Intstream.range (0, 10_000) .foreach (i -> {
    executor.submit (() -> {
        Thread.sleep (duration.ofseconds (1));
        System.out.println ("Selesai:" i);
        kembali null;
    });
});

Ini menanam 10,000 benang maya yang tidur (blok) tanpa membunuh sistem anda. Dengan benang platform, ini akan gagal atau merangkak.

Jadi sekarang, bukannya menulis rantai reaktif kompleks untuk mengelakkan menyekat, anda boleh menulis kod yang mudah dan segerak yang berskala.

3. Adakah ini menjadikan pengaturcaraan reaktif usang?

Tidak sepenuhnya. Di sinilah setiap pendekatan bersinar:

? Gunakan benang maya ketika:

• Anda melakukan kerja saya/O-terikat (misalnya, panggilan HTTP, operasi fail).
• Anda mahu kod mudah dan mudah dibaca .
• Anda tidak memerlukan tekanan belakang atau pemprosesan aliran.
• Anda mengintegrasikan dengan menyekat API (contohnya, JDBC tradisional).

 void handlerequest () {
    var user = db.loadUser (); // menyekat
    var config = service.getConfig (); // menyekat http
    EmailService.Send (pengguna, config);
}

Jalankan salah satu daripada ini setiap benang maya -tidak memerlukan Mono , Flux , atau neraka panggilan balik.

? Pastikan pengaturcaraan reaktif apabila:

• Anda memerlukan tekanan balik (contohnya, pengeluar cepat, pengguna yang perlahan).
• Anda memproses aliran data tak terhingga atau tinggi .
• Anda mahu kawalan halus terhadap penjadualan dan threading .
• Anda berada di persekitaran di mana anda tidak boleh menggunakan Loom (versi Java yang lebih lama).
• Anda bergantung pada ekosistem reaktif (misalnya, Spring WebFlux, R2DBC).

Reaktif masih cemerlang dalam menyusun operasi tak segerak dan mengurus penggunaan sumber di bawah beban yang melampau.

4. Bolehkah mereka bekerjasama?

Ya -dan kadang -kadang itulah pendekatan terbaik.

Anda boleh menjalankan saluran paip reaktif di dalam benang maya , atau menggunakan benang maya sebagai sasaran pelaksanaan untuk tugas reaktif.

Contohnya:

 Mono.FromCallable (() -> SangatExpensiveBlockingOperation ())
    .subscribeon (reactor.core.scheduler.schedulers.FromExecutor (
        Executors.NewVirtualThreadPerTasKexecutor ()
    ));

Sekarang aliran reaktif anda mendapat manfaat daripada menyekat murah melalui benang maya.

Atau, gunakan Reaktor Projek dengan benang maya di Spring Boot 6:

 @Bean
Public Scheduler Virtualthreadscheduler () {
    pulangan penjadual.FromExecutor (executors.NewVirtualThreadPerTasKexecutor ());
}

Kemudian:

 Mono.just ("hello")
    .Publishon (Virtualthreadscheduler ())
    .map (ini :: BlockingTransform)
    .subscribe ();

Model hibrid ini memberi anda yang terbaik dari kedua -dua dunia : kawalan aliran reaktif dengan kecekapan konvensional Loom.

Bottom line

• Projek Loom tidak membunuh pengaturcaraan reaktif - ia mentakrifkan semula peranannya.
• Untuk kebanyakan aplikasi pelayan konvensional , benang maya membuat kod menghalang mudah berskala, mengurangkan keperluan kerumitan reaktif.
• Pengaturcaraan reaktif tetap berharga untuk pemprosesan aliran lanjutan, tekanan belakang, dan integrasi dengan sistem reaktif.
• Masa depan mungkin "reaktif apabila diperlukan, mudah secara lalai."

Jadi, sekiranya anda berhenti menggunakan Reaktor atau WebFlux? Tidak -tetapi menimbang semula jika anda menggunakannya hanya untuk mengelakkan keletihan benang. Dengan tenun, masalah itu sebahagian besarnya diselesaikan.

Pada asasnya: Tulis kod mudah terlebih dahulu. Mencapai reaktif hanya apabila anda memerlukan kuasa uniknya.

Atas ialah kandungan terperinci Pengaturcaraan Reaktif di Java dengan Loom Project dan Thread Maya. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!