说说我的看法,不对的地方请指正。
乐观锁的实现原理是cas操作,java中轻量级锁也是基于cas实现的。
悲观锁最大的问题就是阻塞问题。
在深入理解java虚拟机中提到,轻量级锁一般情况下是优于重量级锁(互斥锁)的;如果在高并发锁竞争比较激烈的情况下轻量级锁会由于长时间自旋消耗cpu 从而使得轻量级锁的性能比传统的重量级锁更慢。那么乐观锁中也有自旋和cas,所以高并发下乐观锁好像不是一种好的解决方案。
但是有些博文中提到 高并发下使用乐观锁更合适
比如这篇文章中就提到高并发数据库访问使用乐观锁
http://blog.csdn.net/amqvje/a...
问题1,高并发下如何选择?
问题2 乐观锁有什么缺点? 为什不都使用乐观锁。高并发下都是使用乐观锁,如果并发量不高,使用乐观锁感觉更不是问题
Ringkasnya, dalam keadaan biasa, penguncian optimistik sesuai untuk operasi yang hanya membaca dan tidak menulis, dan penguncian pesimis sesuai untuk operasi membaca dan menulis bercampur. Jika operasi tulis adalah sangat mudah dan pendek, seperti meningkatkan bilangan pelawat, anda juga boleh menggunakan penguncian optimistik, atau apabila tidak perlu memastikan bahawa data yang dibaca adalah yang terkini. Menggunakan penguncian optimistik sememangnya merupakan pilihan yang lebih baik dalam 80% kes.
CAS bergantung pada sokongan arahan CPU perkakasan untuk melaksanakan operasi tahap atom, jadi ia secara amnya lebih pantas dalam keadaan serentak yang tinggi Walau bagaimanapun, kelajuan ini bukan tanpa kekurangannya ialah apabila terdapat bacaan dan penulisan, cache CPU gagal kadar mungkin meningkat, melainkan CPU anda adalah teras tunggal (platform bukan Intel terbenam).
Ringkasnya, untuk meningkatkan prestasi konkurensi yang tinggi, kami masih memerlukan data terukur yang sebenar untuk menjelaskan masalah yang saya nyatakan di atas adalah semua teori. Semoga ia membantu.
Sama ada kunci pesimis atau kunci optimistik, ia sebenarnya merupakan idea kawalan serentak, dan ia tidak terhad kepada pangkalan data Pilihan khusus kunci optimis dan kunci pesimis adalah berdasarkan senario perniagaan.
Kunci optimis:Kunci pesimistik:
Secara amnya, kunci pesimis yang kami gunakan adalah untuk menambah kunci eksklusif di peringkat pangkalan data Jika kunci berjaya, data boleh diubah suai dan penyerahan transaksi berjaya dibuka gagal, ini bermakna data sedang diubah suai. Jika anda menggunakan innodb mysql, berhati-hati untuk mematikan atribut auto-commit mysql, kerana mysql menggunakan mod autocommit secara lalai, maksudnya, apabila anda melakukan operasi kemas kini, MySQL akan segera menyerahkan hasilnya, dan juga memberi perhatian ke peringkat kunci , secara lalai innodb menggunakan kunci peringkat baris, tetapi kunci peringkat baris adalah berdasarkan indeks Jika sql anda tidak menggunakan indeks, maka mysql akan menggunakan kunci peringkat jadual untuk mengunci jadual.
set autocommit=0
Kebaikan dan Kelemahan:Kunci pesimis ialah strategi konservatif "dapatkan kunci dahulu dan kemudian akses", yang memberikan jaminan untuk keselamatan pemprosesan data. Walau bagaimanapun, dari segi kecekapan, mekanisme penguncian akan menyebabkan overhed tambahan kepada pangkalan data dan meningkatkan peluang kebuntuan. Di samping itu, kerana tidak akan ada konflik dalam pemprosesan transaksi baca sahaja, tidak perlu menggunakan kunci, yang hanya akan meningkatkan beban sistem. Ia juga mengurangkan keselarian Jika transaksi mengunci baris data tertentu, urus niaga lain mesti menunggu transaksi diproses sebelum memproses baris data tersebut.
Kunci optimis sebenarnya mengandaikan bahawa data tidak akan menyebabkan konflik dalam keadaan biasa, jadi apabila data diserahkan untuk kemas kini, konflik data akan dikesan secara rasmi Jika konflik ditemui, pengguna akan dikembalikan Maklumat ralat dan biarkan pengguna memutuskan perkara yang perlu dilakukan.
Kebaikan dan Kelemahan:Secara amnya, ia boleh ditulis terus dalam lapisan logik kod Berbanding dengan kunci pesimis, apabila memproses pangkalan data, kunci optimis tidak menggunakan mekanisme kunci yang disediakan oleh pangkalan data. Ia biasanya dilaksanakan dengan menggunakan nombor versi atau cap waktu. Apabila menggunakan nombor versi, anda boleh menentukan nombor versi semasa pemulaan data, dan setiap operasi kemas kini pada data akan menambah 1 pada nombor versi. Dan tentukan sama ada nombor versi semasa ialah nombor versi terkini data. Seperti:
Penguncian yang optimis percaya bahawa kebarangkalian persaingan data adalah sangat kecil Oleh itu, teruskan secara terus yang mungkin dan jangan kunci sehingga penyerahan, jadi tiada kunci dan kebuntuan akan berlaku. Tetapi jika anda melakukan ini secara ringkas, anda mungkin masih menemui hasil yang tidak dijangka Contohnya, jika dua transaksi membaca baris tertentu pangkalan data dan kemudian menulisnya kembali ke pangkalan data selepas pengubahsuaian, anda akan menghadapi masalah.
Kegagalan penguncian optimistik adalah peristiwa kebarangkalian kecil dan memerlukan kerjasama pelbagai keadaan untuk berlaku. Seperti:
Selepas pengguna A selesai membaca, pengguna B kebetulan memadamkan rekod tersebut. Selepas itu, pengguna C memasukkan rekod baharu.
Pada masa ini, secara tidak sengaja, ID rekod yang baru dimasukkan adalah konsisten dengan ID rekod yang dibaca oleh pengguna A, dan kedua-dua nombor versi ialah nilai lalai 0.
Selepas pengguna C menyelesaikan operasi, pengguna A mengubah suai rekod yang lengkap dan menyimpannya. Memandangkan kedua-dua ID dan versi boleh dipadankan, pengguna A berjaya menyimpan. Walau bagaimanapun, rekod yang dimasukkan oleh pengguna C telah ditimpa.
Sebab asas kegagalan penguncian optimistik pada masa ini ialah strategi pengurusan ID kunci utama yang digunakan oleh aplikasi tidak serasi dengan penguncian optimistik pada tahap yang sangat kecil.
Sebelum saya mula bekerja, saya mempunyai idea yang sama dengan penyoal Dalam kerja sebenar, sebenarnya tidak banyak perbezaan antara kedua-dua bahagian sistem yang paling memakan masa di bawah konkurensi tinggi yang sebenar adalah sambungan rangkaian, pertanyaan pangkalan data dan tidur aktif benang. Pada asasnya boleh diabaikan
Persoalan utama ialah, adakah fakta itu pesimis atau optimis?
Jika persaingan sumber anda sengit dan tidak boleh dikongsi, penguncian optimistik hanya akan mengalahkan harapan sejumlah besar permintaan.
Jika tiada persaingan untuk sumber anda (ini tidak semestinya berkaitan dengan tahap konkurensi, tetapi mempunyai kesan yang lebih besar kepada perniagaan), maka penguncian pesimis bermakna penguncian yang tidak perlu. Jika sumber itu pada asalnya boleh dikongsi (contohnya, sumber itu menyokong berbilang parti baca sahaja), maka penguncian pesimis bermakna kehilangan masa boleh guna asal.
Saya tidak tahu banyak tentang JVM. Tetapi apakah maksud "Putaran dan cas juga wujud dalam penguncian optimistik"? cas ialah kaedah pelaksanaan kunci putaran Mengapakah ia perlu disejajarkan? Apakah maksud "juga"? Penguncian pesimis ialah operasi menyekat, tiada putaran, dan ia tidak terus menggunakan CPU.