Ngopi #113. 5 prekara sing mbokmenawa sampeyan ora ngerti babagan multithreading ing Jawa. 10 Ekstensi JetBrains kanggo Nglawan Utang Teknis

5 Bab sing Sampeyan Mungkin Ora Ngerti Babagan Multithreading ing Jawa

Sumber: DZone Thread minangka inti saka basa pamrograman Jawa. Malah mbukak program Hello World mbutuhake utas utama. Yen perlu, kita bisa nambah utas liyane menyang program yen kita pengin kode aplikasi kita dadi luwih fungsional lan kinerja. Yen kita ngomong babagan server web, banjur proses atusan panjalukan bebarengan. Multiple thread digunakake kanggo iki. Utas temtu migunani, nanging nggarap bisa dadi angel kanggo akeh pangembang. Ing artikel iki, aku bakal nuduhake limang konsep multithreading sing bisa uga ora dingerteni para pangembang anyar lan berpengalaman.

1. Urutan program lan urutan eksekusi ora cocog

Nalika kita nulis kode, kita nganggep bakal nglakokake persis cara kita nulis. Nanging, ing kasunyatan iki ora. Compiler Java bisa ngganti urutan eksekusi kanggo ngoptimalake yen bisa nemtokake manawa output ora bakal diganti ing kode siji-threaded. Deleng cuplikan kode ing ngisor iki:

package ca.bazlur.playground;

import java.util.concurrent.Phaser;

public class ExecutionOrderDemo {
    private static class A {
        int x = 0;
    }

    private static final A sharedData1 = new A();
    private static final A sharedData2 = new A();

    public static void main(String[] args) {
        var phaser = new Phaser(3);
        var t1 = new Thread(() -> {
            phaser.arriveAndAwaitAdvance();
            var l1 = sharedData1;
            var l2 = l1.x;
            var l3 = sharedData2;
            var l4 = l3.x;
            var l5 = l1.x;
            System.out.println("Thread 1: " + l2 + "," + l4 + "," + l5);
        });
        var t2 = new Thread(() -> {
            phaser.arriveAndAwaitAdvance();
            var l6 = sharedData1;
            l6.x = 3;
            System.out.println("Thread 2: " + l6.x);
        });
        t1.start();
        t2.start();
        phaser.arriveAndDeregister();
    }
}

Kode iki katon prasaja. Kita duwe rong conto data sing dienggo bareng ( sharedData1 lan sharedData2 ) sing nggunakake rong utas. Nalika kita nglakokake kode kasebut, kita ngarepake output kaya iki: Nanging yen sampeyan mbukak kode kaping pirang-pirang, sampeyan bakal weruh asil sing beda: Aku ora ngandika sing kabeh lepen iki bakal muter persis kaya iki ing mesin, nanging tanggung bisa.

2. Serat Jawa cacahe diwatesi

Nggawe thread ing Jawa iku gampang. Nanging, iki ora ateges kita bisa nggawe akeh sing dikarepake. Jumlah utas diwatesi. Kita bisa kanthi gampang ngerteni jumlah benang sing bisa digawe ing mesin tartamtu kanthi nggunakake program ing ngisor iki:

package ca.bazlur.playground;

import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.LockSupport;

public class Playground {
    public static void main(String[] args) {
        var counter = new AtomicInteger();
        while (true) {
            new Thread(() -> {
                int count = counter.incrementAndGet();
                System.out.println("thread count = " + count);
                LockSupport.park();
            }).start();
        }
    }
}

Program ndhuwur banget prasaja. Iku nggawe thread ing daur ulang lan banjur taman iku, kang tegese thread dipatèni kanggo mangsa nggunakake nanging nindakake telpon sistem lan allocates memori. Program kasebut terus nggawe benang nganti ora bisa nggawe maneh, banjur mbuwang pengecualian. Kita kasengsem ing nomer sing bakal kita tampa nganti program mbalang pangecualian. Ing komputer, aku mung bisa nggawe 4065 utas.

3. Kakehan benang ora njamin kinerja sing luwih apik

Iku naif kanggo pracaya nggawe thread gampang ing Jawa bakal nambah kinerja aplikasi. Sayange, asumsi iki salah karo model multithreading tradisional sing diwenehake Jawa saiki. Nyatane, akeh banget benang bisa nyuda kinerja aplikasi. Ayo takon pitakonan iki: apa jumlah maksimal benang sing bisa digawe kanggo ngoptimalake kinerja aplikasi? Inggih, jawabanipun boten prasaja. Iku banget gumantung ing jinis karya kita nindakake. Yen kita duwe macem-macem tugas mandiri, kabeh iku komputasi lan ora ngalangi sumber daya eksternal, mula duwe benang sing akeh ora bakal nambah kinerja. Ing tangan liyane, yen kita duwe prosesor 8-inti, nomer paling luweh saka thread bisa dadi (8 + 1). Ing kasus kaya mengkono, kita bisa gumantung ing Utas podo ngenalaken ing Jawa 8. Kanthi gawan, Utas podo nggunakake sambungan Fork / Join pool. Nggawe benang sing padha karo jumlah prosesor sing kasedhiya, sing cukup kanggo bisa digunakake kanthi intensif. Nambahake luwih akeh benang menyang proyek intensif CPU sing ora ana sing diblokir ora bakal nambah kinerja. Nanging, kita mung bakal mbuwang sumber daya. Cathetan. Alesan kanggo duwe utas ekstra iku malah utas komputasi-intensif kadhangkala nyebabake kesalahan kaca utawa ditundha amarga sawetara alasan liyane. (Waca: Java Parallelism in Practice , Brian Goetz, kaca 170) Nanging, umpamane, yen tugas-tugas kasebut terikat karo I/O. Ing kasus iki, padha gumantung ing komunikasi njaba (e.g. database, API liyane), supaya nomer luwih saka Utas ndadekake pangertèn. Alesane yaiku nalika thread nunggu ing Rest API, thread liyane bisa terus digunakake. Saiki kita bisa takon maneh, carane akeh utas kanggo kasus kaya mengkono? gumantung. Ora ana angka sing sampurna sing cocog karo kabeh kasus. Mula, kita kudu nindakake tes sing nyukupi kanggo ngerteni apa sing paling cocog kanggo beban kerja lan aplikasi tartamtu. Ing skenario sing paling khas, kita biasane duwe macem-macem tugas. Lan ing kasus kaya mengkono iku bakal rampung. Ing bukune "Java Concurrency in Practice," Brian Goetz ngusulake rumus sing bisa digunakake ing pirang-pirang kasus. Jumlah utas = Jumlah Inti Kasedhiya * (1 + Wektu ngenteni / Wektu layanan) Wektu tunggu bisa dadi IO, kayata ngenteni respon HTTP, entuk kunci, lan liya-liyane. Wektu Layanan(Wektu layanan) yaiku wektu komputasi, kayata ngolah respon HTTP, marshaling / unmarshaling, lan liya-liyane. Contone, aplikasi nelpon API banjur diproses. Yen kita duwe 8 prosesor ing server aplikasi, rata-rata wektu nanggepi API yaiku 100ms, lan wektu pangolahan respon yaiku 20ms, mula ukuran benang sing cocog yaiku: Nanging, iki oversimplification; testing nyukupi tansah kritis kanggo nemtokake nomer.

4. Multithreading ora paralelisme

Kadhangkala kita nggunakake multithreading lan paralelisme, nanging iki ora cocog maneh. Senajan ing Jawa kita entuk loro nggunakake thread, iku rong bab sing beda. "Ing pemrograman, multithreading minangka kasus khusus tanpa preduli saka proses sing mlaku, lan paralelisme minangka eksekusi simultan (bisa uga ana gandhengane). Multithreading yaiku babagan sesambungan karo akeh perkara ing wektu sing padha. Concurrency nindakake akeh perkara ing wektu sing padha. Dhéfinisi ing ndhuwur sing diwenehake dening Rob Pike cukup akurat. Ayo dadi ngomong kita duwe tugas rampung sawijining, lan padha bisa diwilang dhewe. Ing kasus iki, tugas kasebut diarani paralel lan bisa ditindakake kanthi blumbang Fork / Join utawa benang paralel. Ing sisih liya, yen kita duwe akeh tugas, sawetara bisa uga gumantung marang wong liya. Cara kita nyusun lan struktur diarani multithreading. Iku ana hubungane karo struktur. Kita bisa uga pengin nindakake sawetara tugas bebarengan kanggo entuk asil tartamtu, tanpa kudu rampung luwih cepet.

5. Project Loom ngidini kita nggawe jutaan benang

Ing titik sadurunge, aku mbantah manawa duwe luwih akeh benang ora ateges kinerja aplikasi sing luwih apik. Nanging, ing jaman layanan mikro, kita sesambungan karo akeh banget layanan kanggo ngrampungake karya tartamtu. Ing skenario kaya mengkono, utas tetep ing negara diblokir paling wektu. Nalika OS modern bisa nangani mayuta-yuta soket mbukak, kita ora bisa mbukak akeh saluran komunikasi amarga kita diwatesi kanthi jumlah benang. Nanging kepiye yen sampeyan nggawe jutaan benang, lan saben-saben nggunakake soket sing mbukak kanggo komunikasi karo jagad njaba? Iki mesthi bakal nambah throughput aplikasi kita. Kanggo ndhukung gagasan iki, ana inisiatif ing Jawa sing diarani Project Loom. Nggunakake, kita bisa nggawe mayuta-yuta thread virtual. Contone, nggunakake snippet kode ing ngisor iki, aku bisa nggawe 4,5 yuta utas ing mesin.

import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.LockSupport;

public class Main {
    public static void main(String[] args) {
        var counter = new AtomicInteger();

        // 4_576_279
        while (true) {
            Thread.startVirtualThread(() -> {
                int count = counter.incrementAndGet();
                System.out.println("thread count = " + count);
                LockSupport.park();
            });
        }
    }
}

Kanggo mbukak program iki sampeyan kudu nginstal Java 18, sing bisa didownload ing kene . Sampeyan bisa mbukak kode nggunakake printah ing ngisor iki: java --source 18 --enable-preview Main.java

10 Ekstensi JetBrains kanggo Nglawan Utang Teknis

Sumber: DZone Akeh tim pangembang ngrasakake tekanan gedhe kanggo ngrampungake tenggat wektu. Amarga iki, dheweke asring ora duwe cukup wektu kanggo ndandani lan ngresiki basis kode. Kadhangkala ing kahanan kasebut, utang teknis cepet akumulasi. Ekstensi editor bisa mbantu ngatasi masalah iki. Ayo goleki 10 ekstensi JetBrains paling apik kanggo nglawan utang teknis (kanthi dhukungan Jawa).

Refactoring lan alat utang teknis

1. RefactorInsight

RefactorInsight nambah visibilitas owah-owahan kode ing IDE kanthi menehi informasi babagan refactorings.

1. Ekstensi kasebut nemtokake refactorings ing panjalukan gabungan.
2. Tandha nindakake sing ngemot refactorings.
3. Mbantu ndeleng refactoring saka komit tartamtu sing dipilih ing tab Log Git.
4. Nuduhake riwayat refactoring kelas, metode, lan kolom.

2. Stepsize Issue Tracker ing IDE

Stepsize minangka tracker masalah sing apik kanggo pangembang. Ekstensi kasebut mbantu para insinyur ora mung nggawe TODO lan komentar kode sing luwih apik, nanging uga prioritas utang teknis, refactorings, lan liya-liyane:

1. Stepsize ngidini sampeyan nggawe lan ndeleng tugas ing kode langsung ing editor.
2. Temokake masalah sing mengaruhi fitur sing lagi digunakake.
3. Tambah masalah menyang sprint sampeyan nggunakake integrasi Jira, Asana, Linear, Azure DevOps, lan GitHub.

3. New Relic CodeStream

New Relic CodeStream minangka platform kolaborasi pangembang kanggo ngrembug lan mriksa kode. Ndhukung panjaluk tarik saka GitHub, BitBucket lan GitLab, manajemen masalah saka Jira, Trello, Asana lan 9 liyane, lan nyedhiyakake diskusi kode, nggabungake kabeh.

1. Gawe, deleng, lan gabungake panjaluk tarik ing GitHub.
2. Entuk umpan balik babagan karya sing lagi ditindakake kanthi ulasan kode awal.
3. Ngrembug masalah kode karo kanca-kanca.

TODO lan komentar

4. Komentar Highlighter

Plugin iki ngidini sampeyan nggawe sorotan khusus baris komentar lan tembung kunci basa. Plugin uga nduweni kemampuan kanggo nemtokake token khusus kanggo nyorot baris komentar.

5. Komentar sing luwih apik

Ekstensi Komentar Luwih apik mbantu sampeyan nggawe komentar sing luwih jelas ing kode sampeyan. Kanthi ekstensi iki, sampeyan bakal bisa nggolongake anotasi dadi:

1. Tandha.
2. Njaluk.
3. TODO.
4. wayahe dhasar.

Bug lan kerentanan keamanan

6. SonarLint _

SonarLint ngidini sampeyan ngatasi masalah kode sadurunge muncul. Uga bisa digunakake minangka pamriksa ejaan. SonarLint nyorot bug lan kerentanan keamanan nalika sampeyan nggawe kode, kanthi instruksi remediasi sing jelas supaya sampeyan bisa ndandani sadurunge kode kasebut ditindakake.

7. SpotBugs

Plugin SpotBugs nyedhiyakake analisis bytecode statis kanggo nemokake bug ing kode Jawa saka IntelliJ IDEA. SpotBugs minangka alat deteksi cacat kanggo Jawa sing nggunakake analisis statis kanggo nemokake luwih saka 400 pola bug kayata null pointer dereferences, loop rekursif tanpa wates, nyalahi panggunaan perpustakaan Jawa, lan deadlock. SpotBugs bisa ngenali atusan cacat serius ing aplikasi gedhe (biasane kira-kira 1 cacat saben 1000-2000 baris saka statement uncommented mentah).

8. Scanner Kerentanan Snyk

Snyk's Vulnerability Scanner mbantu sampeyan nemokake lan ndandani kerentanan keamanan lan masalah kualitas kode ing proyek sampeyan.

1. Nggoleki lan ndandani masalah keamanan.
2. Deleng dhaptar macem-macem jinis masalah, dipérang dadi kategori.
3. Nampilake tips ngatasi masalah.

9. Zero Width Karakter Locator

Plugin iki nambah mriksa lan ndeteksi kesalahan sing angel ditemokake sing ana hubungane karo karakter lebar nol sing ora katon ing kode sumber lan sumber daya. Nalika nggunakake, priksa manawa mriksa "karakter unicode jembare Zero" diaktifake.

10. KodeMR _

CodeMR minangka kualitas piranti lunak lan alat analisis kode statis sing mbantu perusahaan piranti lunak ngembangake kode lan program sing luwih apik. CodeMR nggambarake metrik kode lan atribut kualitas tingkat dhuwur (gandeng, kerumitan, kohesi, lan ukuran) ing macem-macem tampilan kayata Struktur Paket, TreeMap, Sunburst, Dependensi, lan Tampilan Grafik.