Adakah anda menggunakan kunci yang betul? Perbincangan ringkas mengenai "kunci" Java penting

Dalam setiap era, mereka yang tahu bagaimana untuk belajar tidak akan dilayan dengan teruk

Saya baru-baru ini mendapati bahawa rakan sekerja baru dalam syarikat mempunyai beberapa salah faham tentang kunci, jadi hari ini mari kita bercakap tentang "kunci" dan bekas keselamatan serentak dalam Java Apakah langkah berjaga-jaga untuk digunakan?

Tetapi sebelum itu, kita masih perlu menjelaskan mengapa kita perlu mengunci perkara ini. Ini bermula dari sumber pepijat konkurensi.

Sumber concurrency bugs

Saya menulis artikel mengenai isu ini pada tahun 2019. Melihat kembali artikel itu sekarang, saya berasa sangat malu.

Mari kita lihat sumbernya Kita tahu bahawa komputer mempunyai CPU, memori, dan cakera keras Kelajuan membaca cakera keras adalah yang paling perlahan, diikuti dengan bacaan memori . Bacaan memori adalah lebih perlahan daripada operasi CPU Ia terlalu perlahan, jadi saya mencipta satu lagi cache CPU, L1, L2 dan L3.

Inilah CPU cache ditambah dengan situasi CPU berbilang teras semasa yang menghasilkan BUG serentak.

Ini adalah kod yang sangat mudah Jika terdapat thread A dan thread B masing-masing melaksanakan kaedah ini dalam CPU-A dan CPU-B, operasi mereka adalah untuk mengakses a dari memori utama masing-masing ke CPU cache, nilai a dalam cache mereka semuanya 0 pada masa ini.

Kemudian mereka melaksanakan a++ masing-masing Pada masa ini, nilai a di mata masing-masing ialah 1. Apabila a dipancarkan ke memori utama nanti, nilai a masih 1. Ini adalah masalah penambahan terakhir satu dilaksanakan dua kali Hasilnya ialah 1, bukan 2.

Masalah ini dipanggil masalah penglihatan.

Melihat kenyataan a++ kami, bahasa kami sekarang adalah bahasa peringkat tinggi Ini sebenarnya sangat serupa dengan gula sintaksis arahan yang benar-benar perlu dilaksanakan.

Sesuatu pernyataan dalam bahasa peringkat tinggi boleh diterjemahkan ke dalam lebih daripada satu arahan CPU Sebagai contoh, a++ boleh diterjemahkan ke dalam sekurang-kurangnya tiga arahan CPU.

• Dapatkan daripada memori untuk mendaftar;

• +1 dalam daftar; mengganggu pernyataan kerana ia adalah atom Sebenarnya, CPU boleh melaksanakan arahan apabila potongan masa tamat Pada masa ini, konteks beralih ke urutan lain, yang juga melaksanakan a++. Apabila anda menukar kembali semula, nilai a sebenarnya salah.

Masalah ini dipanggil masalah atomicity
• .

  Dan untuk mengoptimumkan prestasi, pengkompil atau jurubahasa boleh mengubah susunan pelaksanaan pernyataan Ini dipanggil penyusunan semula arahan. Untuk meningkatkan kecekapan pelaksanaan, CPU akan melaksanakan di luar perintah Contohnya, apabila CPU sedang menunggu data memori dimuatkan, ia mendapati bahawa arahan tambahan berikut tidak bergantung pada hasil pengiraan arahan sebelumnya, jadi. ia melaksanakan arahan penambahan terlebih dahulu.

Masalah ini dipanggil masalah tempahan

.

Kini kami telah menganalisis sumber pepijat konkurensi, iaitu tiga masalah utama ini. Ia boleh dilihat bahawa sama ada ia adalah cache CPU, CPU berbilang teras, bahasa peringkat tinggi atau penyusunan semula yang tidak teratur, ia sebenarnya perlu, jadi kita hanya boleh menghadapi masalah ini secara langsung.

Untuk menyelesaikan masalah ini ialah melumpuhkan caching, melarang penyusunan semula arahan pengkompil, pengecualian bersama, dll. Hari ini topik kami berkaitan dengan pengecualian bersama.

Pengecualian bersama memastikan pengubahsuaian kepada pembolehubah dikongsi adalah saling eksklusif, iaitu, hanya satu urutan dilaksanakan pada masa yang sama. Apabila bercakap tentang pengecualian bersama, saya percaya apa yang terlintas di fikiran semua orang ialah

kunci

. Ya, topik kita hari ini adalah kunci! Kunci direka untuk menyelesaikan masalah atomicity.

Kunci

Apabila bercakap tentang kunci, reaksi pertama pelajar Java ialah kata kunci yang disegerakkan, ia disokong pada peringkat bahasa. Mari kita lihat disegerakkan dahulu Sesetengah pelajar tidak memahami disegerakkan dengan baik, jadi terdapat banyak perangkap dalam menggunakannya.

Nota disegerakkan

Mari kita lihat kod ini dahulu adalah cara kita untuk meningkatkan gaji. Dan benang sentiasa membandingkan sama ada gaji kita sama. Biar saya katakan IntStream .rangeClosed(1,1000000).forEach, sesetengah orang mungkin tidak biasa dengan ini kod ini bersamaan dengan gelung for 1 juta kali. IntStream.rangeClosed(1,1000000).forEach，可能有些人对这个不太熟悉，这个代码的就等于 for 循环了100W次。

你先自己理解下，看看觉得有没有什么问题？第一反应好像没问题，你看着涨工资就一个线程执行着，这比工资也没有修改值，看起来好像没啥毛病？没有啥并发资源的竞争，也用 volatile 修饰了保证了可见性。

让我们来看一下结果，我截取了一部分。

可以看到首先有 log 打出来就已经不对了，其次打出来的值竟然还相等！有没有出乎你的意料之外？有同学可能下意识就想到这就raiseSalary在修改，所以肯定是线程安全问题来给raiseSalary 加个锁！

请注意只有一个线程在调用raiseSalary方法，所以单给raiseSalary

Anda harus memahaminya sendiri dahulu dan lihat jika anda merasakannya Apa masalahnya? Reaksi pertama nampaknya baik apabila melihat kenaikan gaji, ia dilaksanakan dalam satu utas Ini tidak mengubah nilai gaji. Tiada persaingan untuk sumber serentak, dan ia dihiasi dengan tidak menentu untuk memastikan keterlihatan. 🎜🎜Mari kita lihat hasilnya, saya ambil tangkapan skrin. 🎜

🎜Anda boleh melihat bahawa log dicetak terlebih dahulu dan ia adalah sudah salah. Maka nilai yang dicetak sebenarnya sama! Adakah sesuatu yang mengejutkan anda? Sesetengah pelajar mungkin secara tidak sedar memikirkanraiseSalary sedang diubah suai, jadi ia mesti menjadi isu keselamatan urutan untuk naikkanGaji Tambah kunci! 🎜🎜Sila ambil perhatian bahawa hanya terdapat satu urutan yang memanggil naikkanGaji kaedah, jadi hanya berikan naikkanGaji penguncian kaedah tidak berguna. 🎜

Ini sebenarnya masalah atomicity yang saya nyatakan di atas. Bayangkan bahawa benang kenaikan gaji selesai melaksanakanyesGaji++belum dilaksanakan lagiyourGaji++, utas gaji hanya melaksanakan untukyesGaji != yourGaji Adakah ia pasti benar? Itulah sebabnya log dicetak. yesSalary++还未执行yourSalary++时，比工资线程刚好执行到yesSalary != yourSalary 是不是肯定是 true ？所以才会打印出 log。

再者由于用 volatile 修饰保证了可见性，所以当打 log 的时候，可能yourSalary++已经执行完了，这时候打出来的 log 才会是yesSalary == yourSalary。

所以最简单的解决办法就是把raiseSalary() 和 compareSalary() 都用 synchronized 修饰，这样涨工资和比工资两个线程就不会在同一时刻执行，因此肯定就安全了！

看起来锁好像也挺简单，不过这个 synchronized 的使用还是对于新手来说还是有坑的，就是你要关注 synchronized 锁的究竟是什么。

比如我改成多线程来涨工资。这里再提一下parallel

Selain itu, oleh kerana hiasan yang tidak menentu digunakan untuk memastikan keterlihatan, apabila log, ia mungkin yourSalary++ telah dilaksanakan dan output log pada masa ini ialah yesGaji == yourGaji. 🎜🎜Jadi penyelesaian paling mudah ialah meletakkan naikkanGaji() dan compareSalary() semuanya diubah suai dengan disegerakkan, supaya dua urutan kenaikan gaji dan perbandingan gaji tidak akan dilaksanakan pada masa yang sama, jadi ia pasti selamat! 🎜

🎜Nampaknya kuncinya agak mudah, tetapi ini disegerakkan Masih terdapat perangkap untuk pemula dalam menggunakannya, iaitu, anda perlu memberi perhatian kepada kunci yang disegerakkan. 🎜🎜Contohnya saya tukar kepada multi-threading untuk naikkan gaji. Biar saya sebutkan sekali lagiparallel , ini sebenarnya menggunakan operasi kumpulan benang ForkJoinPool, dan bilangan utas lalai ialah bilangan teras CPU. 🎜

Disebabkan oleh raiseSalary() 加了锁，所以最终的结果是对的。这是因为 synchronized 修饰的是yesLockDemo, hanya terdapat satu kejadian dalam utama kami, jadi apa yang dipertandingkan oleh pelbagai benang ialah kunci, jadi data pengiraan akhir adalah betul.

Kemudian saya akan mengubah suai kod supaya setiap thread mempunyai instance yesLockDemo sendiri untuk menaikkan gaji.

Anda akan tahu kenapa kunci ini tidak berguna? Gaji tahunan yang dijanjikan sebanyak satu juta akan ditukar kepada 100,000? ? Nasib baik, anda masih mempunyai 70w.

Ini kerana kunci kami mengubah suai kaedah bukan statik pada masa ini, iaitu kunci peringkat contoh, dan kami telah mencipta tika untuk setiap utas, jadi apa yang dipertandingkan oleh utas ini bukanlah kunci sama sekali , dan kod yang betul untuk pengiraan berbilang benang di atas adalah kerana setiap utas menggunakan contoh yang sama, jadi ia bersaing untuk mendapatkan kunci. Jika anda mahu kod pada masa ini betul, anda hanya perlu menukar kunci peringkat contoh kepada kunci peringkat kelas.

Ia sangat mudah Anda hanya perlu menukar kaedah ini kepada kaedah statik mengubah suai kaedah statik adalah kunci peringkat kelas.

Cara lain ialah dengan mengisytiharkan pembolehubah statik, yang lebih disyorkan, kerana menukar kaedah bukan statik kepada kaedah statik sebenarnya bersamaan dengan menukar struktur kod. Ringkasnya. -kaedah statik, ia adalah kunci peringkat contoh

.

lock granularity

i percaya semua orang tahu bahawa hashtable tidak disyorkan. cara yang sama. Mari kita lihat kod sumber.

Adakah anda rasa kandungan ini ada kaitan dengan kaedah saiz? Mengapa saya tidak dibenarkan melaraskan saiz apabila saya memanggil mengandungi? Ini kerana butiran kunci adalah terlalu kasar.

Tetapi kunci yang berbeza untuk kaedah yang berbeza tidak mencukupi, kerana kadangkala sesetengah operasi dalam sesuatu kaedah sebenarnya selamat untuk benang, Hanya kod yang melibatkan persaingan untuk sumber perlumbaan perlu dikunci. Terutama jika kod yang tidak memerlukan kunci sangat memakan masa, ia akan menduduki kunci untuk masa yang lama, dan benang lain hanya boleh menunggu dalam barisan, seperti kod berikut.

Jelas sekali kod kedua adalah cara biasa untuk menggunakan kunci, tetapi dalam kod perniagaan biasa ia tidak semudah dilihat sekilas seperti tidur yang disiarkan dalam kod saya Kadangkala ia perlu diubah suai . Susunan pelaksanaan kod dan seterusnya memastikan butiran kunci cukup baik.

Kadangkala kita perlu memastikan kunci itu cukup tebal, tetapi bahagian JVM ini akan dikesan dan ia akan membantu kita mengoptimumkannya, seperti kod berikut.

Anda dapat melihat bahawa logik yang dipanggil dalam kaedah telah melalui 加锁-执行A-解锁-加锁-执行B-解锁，很明显的可以看出其实只需要经历加锁-执行A-执行B-解锁.

Jadi JVM akan mengasarkan kunci semasa penyusunan tepat masa dan mengembangkan skop kunci, sama seperti situasi berikut.

Dan JVM juga akan mempunyai penghapusan kuncitindakan Ia dinilai melalui analisis melarikan diri bahawa objek contoh adalah peribadi benang, maka ia mesti selamat untuk benang, jadi tindakan mengunci dalam objek akan diabaikan. dan dipanggil terus.

Kunci baca-tulis

Kunci baca-tulis ialah apa yang kami serahkan di atas untuk mengurangkan butiran kunci mengikut senario Ia membahagikan kunci kepada kunci baca dan kunci tulis, terutamanya kunci tulis sesuai untuk situasi yang lebih banyak membaca dan kurang menulis Gunakan , contohnya, laksanakan cache sendiri. . baca-tulis adalah saling eksklusif. Secara terang-terangan, apabila menulis, hanya satu benang boleh menulis, dan benang lain tidak boleh membaca atau menulis.

Mari kita lihat contoh kecil, yang juga mempunyai butiran kecil. Kod ini adalah untuk mensimulasikan bacaan cache Pertama, kunci baca digunakan untuk mendapatkan data daripada cache Jika tiada data dalam cache, kunci baca dilepaskan data daripada pangkalan data, dan kemudian data disumbat ke dalam cache dan dikembalikan. Perincian kecil di sini adalah untuk menilai semula , dan kemudian cache kosong, jadi mereka semua bersaing untuk kunci tulis Pada akhirnya, hanya satu utas akan mendapat kunci tulis dahulu, dan kemudian mengisi data ke dalam cache. Pada masa ini, benang menunggu akhirnya akan mendapat kunci tulis satu demi satu Apabila memperoleh kunci tulis, sudah ada nilai dalam cache, jadi tidak perlu menanyakan pangkalan data lagi.

Sudah tentu, semua orang tahu paradigma penggunaan Lock Anda perlu menggunakan cuba-akhirnya untuk memastikan ia akan dibuka kuncinya. Terdapat satu lagi perkara penting yang perlu diperhatikan tentang kunci baca-tulis, iaitu try- finally，来保证一定会解锁。而读写锁还有一个要点需要注意，也就是说锁不能升级。什么意思呢？我改一下上面的代码。

但是写锁内可以再用读锁，来实现锁的降级，有些人可能会问了这写锁都加了还要什么读锁。

还是有点用处的，比如某个线程抢到了写锁，在写的动作要完毕的时候加上读锁，接着释放了写锁，此时它还持有读锁可以保证能马上使用写锁操作完的数据，而别的线程也因为此时写锁已经没了也能读数据。

其实就是当前已经不需要写锁这种比较霸道的锁！所以来降个级让大家都能读。

小结一下，读写锁适用于读多写少的情况，无法升级，但是可以降级。Lock 的锁需要配合 try- finallykunci tidak boleh dinaik taraf

. Apakah maksudnya? Biar saya tukar kod di atas.

Tetapi kunci baca boleh digunakan semula di dalam kunci tulis . Untuk merealisasikan turun taraf kunci, sesetengah orang mungkin bertanya mengapa kunci baca diperlukan selepas kunci tulis ditambah.

It masih berguna. untuk memastikan penulisan dapat digunakan dengan segera Selepas mengunci data, benang lain juga boleh membaca data kerana kunci tulis hilang pada masa ini

. Sebenarnya, tidak ada keperluan untuk kunci yang lebih sombong seperti kunci tulis! Jadi mari kita turun tarafnya supaya semua orang boleh membacanya.

Untuk meringkaskan, kunci baca-tulis sesuai untuk situasi di mana terdapat lebih banyak bacaan dan kurang penulisan Ia tidak boleh dinaik taraf, tetapi ia boleh diturunkan. Kunci perlu sepadan dengan cuba -akhirnya untuk memastikan ia akan dibuka kuncinya. Sebenarnya, izinkan saya menyebut secara ringkas pelaksanaan kunci baca-tulis Pelajar yang biasa dengan AQS mungkin mengetahui keadaan di dalam Kunci baca-tulis membahagikan keadaan jenis int kepada dua bahagian, iaitu 16 bit tinggi dan 16 bit rendah masing-masing merekodkan status kunci baca dan kunci tulis. Perbezaan antara kunci mutex biasa dan kunci mutex terletak pada mengekalkan kedua-dua keadaan ini dan mengendalikan kedua-dua kunci ini secara berbeza dalam barisan menunggu.

Jadi

dalam senario yang tidak sesuai untuk kunci baca-tulis, lebih baik menggunakan kunci mutex secara terus

, kerana kunci baca-tulis juga perlu melakukan pertimbangan anjakan pada keadaan dan operasi lain.

🎜🎜🎜StampedLock🎜🎜🎜🎜🎜Saya juga ingin menyebut sedikit perkara ini, ia adalah 1.8 dan kadar penampilannya nampaknya tidak setinggi ReentrantReadWriteLock. Ia menyokong kunci tulis, kunci baca pesimis dan bacaan optimistik. Kunci tulis dan kunci baca yang pesimis sebenarnya sama dengan kunci baca tulis dalam ReentrantReadWriteLock, yang mempunyai bacaan optimistik tambahan. 🎜🎜Daripada analisis di atas, kita tahu bahawa kunci baca-tulis sebenarnya tidak dapat menulis semasa membaca, 🎜dan pembacaan StampedLock yang optimis membolehkan satu utas menulis🎜. Pembacaan optimistik sebenarnya sama dengan penguncian optimistik pangkalan data yang kita tahu Penguncian optimistik pangkalan data dinilai oleh medan versi, seperti sql berikut. 🎜

StampedLock Bacaan Optimis serupa dengannya, mari kita lihat penggunaannya yang mudah.

Di sinilah ia membandingkan dengan ReentrantReadWriteLock Lain-lain adalah tidak baik Contohnya, StampedLock tidak menyokong kemasukan semula dan tidak menyokong pembolehubah keadaan. Perkara lain ialah apabila menggunakan StampedLock, anda tidak boleh memanggil operasi gangguan, kerana ia akan menyebabkan CPU menjadi 100% Saya menjalankan contoh yang disediakan di laman web Concurrent Programming dan menghasilkannya semula.

Sebab khusus tidak akan dihuraikan di sini Pautan akan disiarkan pada akhir artikel di atas.

Jadi apabila sesuatu yang nampaknya berkuasa keluar, anda perlu benar-benar memahaminya dan membiasakannya untuk menjadi sasaran.

CopyOnWrite

Copy-on-write juga digunakan di banyak tempat, seperti prosesfork() operasi. Ia juga sangat membantu untuk tahap kod perniagaan kami kerana operasi bacanya tidak menyekat penulisan, dan operasi tulis tidak menyekat bacaan. Sesuai untuk senario yang banyak membaca dan sedikit tulisan. fork() 操作。对于我们业务代码层面而言也是很有帮助的，在于它的读操作不会阻塞写，写操作也不会阻塞读。适用于读多写少的场景。

例如 Java 中的实现 CopyOnWriteArrayList，有人可能一听，这玩意线程安全读的时候还不会阻塞写，好家伙就用它了！

你得先搞清楚，写时复制是会拷贝一份数据，你的任何一个修改动作在CopyOnWriteArrayList 中都会触发一次Arrays.copyOf

Sebagai contoh, pelaksanaan dalam JavaCopyOnWriteArrayList, sesetengah orang mungkin mendengar bahawa perkara ini tidak menyekat penulisan apabila ia selamat untuk dibaca, jadi orang yang baik menggunakannya! . 2px 4px ;jejari sempadan: 4px;margin-kanan: 2px;margin-kiri: 2px;warna latar belakang: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo , monospace ;word-break: break-all;color: rgb(60, 112, 198);">CopyOnWriteArrayList akan dicetuskan sekaliArrays.copyOf, dan kemudian ubah suai salinan. Jika terdapat banyak tindakan pengubahsuaian dan data yang disalin juga besar, ini akan menjadi bencana! 🎜

Bekas keselamatan serentak

Akhir sekali, mari kita bercakap tentang penggunaan bekas keselamatan serentak Saya akan mengambil ConcurrentHashMap yang agak biasa sebagai contoh. Saya rasa rakan sekerja baharu nampaknya berfikir bahawa selagi mereka menggunakan bekas keselamatan serentak, mereka mesti selamat untuk benang. Malah, tidak semestinya, ia bergantung pada cara menggunakannya.

Mari kita lihat kod berikut terlebih dahulu, secara ringkasnya, ia menggunakan ConcurrentHashMap untuk merekodkan gaji semua orang, sehingga 100.

Keputusan akhir akan melebihi standard iaitu bukan 100 orang sahaja yang direkodkan dalam peta. Jadi bagaimana hasilnya boleh betul? Ia semudah menambah kunci.

Seseorang berkata selepas melihat ini, mengapa saya perlu menggunakan ConcurrentHashMap jika anda sudah menguncinya, saya hanya boleh menambah kunci pada HashMap dan ia akan baik! Ya anda betul! Kerana senario penggunaan semasa kami ialah operasi kompaun, iaitu, kami menilai saiz peta dahulu, dan kemudian melaksanakan kaedah letak ConcurrentHashMap tidak dapat menjamin bahawa operasi kompaun adalah selamat untuk benang !

Dan ConcurrentHashMap hanya sesuai Gunakan. ia untuk mendedahkan kaedah selamat benang dan bukannya operasi kompaun. Sebagai contoh, kod berikut

Sudah tentu, contoh saya tidak cukup sesuai Malah, sebab mengapa ConcurrentHashMap mempunyai prestasi yang lebih tinggi daripada HashMap + lock adalah disebabkan penguncian bersegmen, yang memerlukan berbilang operasi utama untuk dicerminkan. Walau bagaimanapun, perkara utama yang saya ingin ketengahkan ialah penggunaan Anda tidak boleh cuai, dan anda tidak boleh hanya berfikir bahawa menggunakannya akan menjadikannya selamat untuk benang.

Untuk meringkaskan

Hari ini kita bercakap tentang sumber pepijat konkurensi, iaitu tiga isu utama: isu keterlihatan, isu atomicity dan isu pesanan. Kemudian saya bercakap secara ringkas tentang perkara utama kata kunci yang disegerakkan, iaitu, mengubah suai medan statik atau kaedah statik ialah kunci peringkat kelas, manakala mengubah suai medan bukan statik dan kaedah bukan statik ialah kelas peringkat contoh.

Mari kita bincangkan tentang kebutiran kunci Mentakrifkan kunci yang berbeza dalam senario yang berbeza tidak boleh dilakukan dengan hanya satu kunci, dan kebutiran kunci dalaman kaedah itu mestilah baik. Sebagai contoh, dalam senario di mana terdapat banyak bacaan dan sedikit tulisan, kunci baca-tulis, salin-tulis, dan lain-lain boleh digunakan.

Akhirnya, kita mesti menggunakan bekas keselamatan serentak dengan betul.

Sudah tentu, saya baru sahaja membincangkannya secara ringkas hari ini sebenarnya terdapat banyak perkara tentang pengaturcaraan serentak Tidak mudah untuk menulis kod selamat berbenang, sama seperti keseluruhan proses pemprosesan acara Kafka yang saya analisis sebelum ini. versi asal adalah mengenai konkurensi dan keselamatan yang dikawal oleh pelbagai kunci Kemudian, pepijat tidak dapat dibetulkan sama sekali adalah sukar, penyahpepijatan adalah sukar, dan pembetulan pepijat juga sukar.

Jadi modul pemprosesan acara Kafka akhirnya ditukar kepada mod baris gilir acara satu utas, yang mengasingkan akses yang berkaitan dengan persaingan data kongsi ke dalam acara, memasukkan acara ke dalam baris gilir menyekat, dan kemudian memprosesnya dalam satu utas .

Jadi sebelum guna kunci, kita kena fikir dulu, perlu ke? Bolehkah ia dipermudahkan? Jika tidak, anda akan tahu betapa peritnya untuk mengekalkannya nanti.

Atas ialah kandungan terperinci Adakah anda menggunakan kunci yang betul? Perbincangan ringkas mengenai "kunci" Java penting. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!