建站
咨詢
售后
建站咨詢
新聞中心
一、資源和加鎖
十余年的九原網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。營(yíng)銷型網(wǎng)站建設(shè)的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整九原建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“九原網(wǎng)站設(shè)計(jì)”,“九原網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
1、場(chǎng)景描述
多線程并發(fā)訪問(wèn)同一個(gè)資源問(wèn)題，假如線程A獲取變量之后修改變量值，線程C在此時(shí)也獲取變量值并且修改，兩個(gè)線程同時(shí)并發(fā)處理一個(gè)變量，就會(huì)導(dǎo)致并發(fā)問(wèn)題。
這種并行處理數(shù)據(jù)庫(kù)的情況在實(shí)際的業(yè)務(wù)開(kāi)發(fā)中很常見(jiàn)，兩個(gè)線程先后修改數(shù)據(jù)庫(kù)的值，導(dǎo)致數(shù)據(jù)有問(wèn)題，該問(wèn)題復(fù)現(xiàn)的概率不大，處理的時(shí)候需要對(duì)整個(gè)模塊體系有概念，才能容易定位問(wèn)題。
2、演示案例
- public class LockThread01 {
- public static void main(String[] args) {
- CountAdd countAdd = new CountAdd() ;
- AddThread01 addThread01 = new AddThread01(countAdd) ;
- addThread01.start();
- AddThread02 varThread02 = new AddThread02(countAdd) ;
- varThread02.start();
- }
- }
- class AddThread01 extends Thread {
- private CountAdd countAdd ;
- public AddThread01 (CountAdd countAdd){
- this.countAdd = countAdd ;
- }
- @Override
- public void run() {
- countAdd.countAdd(30);
- }
- }
- class AddThread02 extends Thread {
- private CountAdd countAdd ;
- public AddThread02 (CountAdd countAdd){
- this.countAdd = countAdd ;
- }
- @Override
- public void run() {
- countAdd.countAdd(10);
- }
- }
- class CountAdd {
- private Integer count = 0 ;
- public void countAdd (Integer num){
- try {
- if (num == 30){
- count = count + 50 ;
- Thread.sleep(3000);
- } else {
- count = count + num ;
- }
- System.out.println("num="+num+";count="+count);
- } catch (Exception e){
- e.printStackTrace();
- }
- }
- }
這里案例演示多線程并發(fā)修改count值，導(dǎo)致和預(yù)期不一致的結(jié)果，這是多線程并發(fā)下最常見(jiàn)的問(wèn)題，尤其是在并發(fā)更新數(shù)據(jù)時(shí)。
出現(xiàn)并發(fā)的情況時(shí)，就需要通過(guò)一定的方式或策略來(lái)控制在并發(fā)情況下數(shù)據(jù)讀寫的準(zhǔn)確性，這被稱為并發(fā)控制，實(shí)現(xiàn)并發(fā)控制手段也很多，最常見(jiàn)的方式是資源加鎖，還有一種簡(jiǎn)單的實(shí)現(xiàn)策略：修改數(shù)據(jù)前讀取數(shù)據(jù)，修改的時(shí)候加入限制條件，保證修改的內(nèi)容在此期間沒(méi)有被修改。
二、鎖的概念簡(jiǎn)介
1、鎖機(jī)制簡(jiǎn)介
并發(fā)編程中一個(gè)最關(guān)鍵的問(wèn)題，多線程并發(fā)處理同一個(gè)資源，防止資源使用的沖突一個(gè)關(guān)鍵解決方法，就是在資源上加鎖：多線程序列化訪問(wèn)。鎖是用來(lái)控制多個(gè)線程訪問(wèn)共享資源的方式，鎖機(jī)制能夠讓共享資源在任意給定時(shí)刻只有一個(gè)線程任務(wù)訪問(wèn)，實(shí)現(xiàn)線程任務(wù)的同步互斥，這是最理想但性能最差的方式，共享讀鎖的機(jī)制允許多任務(wù)并發(fā)訪問(wèn)資源。
2、悲觀鎖
悲觀鎖，總是假設(shè)每次每次被讀取的數(shù)據(jù)會(huì)被修改，所以要給讀取的數(shù)據(jù)加鎖，具有強(qiáng)烈的資源獨(dú)占和排他特性，在整個(gè)數(shù)據(jù)處理過(guò)程中，將數(shù)據(jù)處于鎖定狀態(tài)，例如synchronized關(guān)鍵字的實(shí)現(xiàn)就是悲觀機(jī)制。
悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫(kù)提供的鎖機(jī)制，只有數(shù)據(jù)庫(kù)層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問(wèn)的排他性，否則，即使在本系統(tǒng)中實(shí)現(xiàn)了加鎖機(jī)制，也無(wú)法保證外部系統(tǒng)不會(huì)修改數(shù)據(jù)，悲觀鎖主要分為共享讀鎖和排他寫鎖。
排他鎖基本機(jī)制：又稱寫鎖，允許獲取排他鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)取得相同的資源的共享讀鎖和排他鎖。若事務(wù)T對(duì)數(shù)據(jù)對(duì)象A加上寫鎖，事務(wù)T可以讀A也可以修改A，其他事務(wù)不能再對(duì)A加任何鎖，直到T釋放A上的寫鎖。
3、樂(lè)觀鎖
樂(lè)觀鎖相對(duì)悲觀鎖而言，采用更加寬松的加鎖機(jī)制。悲觀鎖大多數(shù)情況下依靠數(shù)據(jù)庫(kù)的鎖機(jī)制實(shí)現(xiàn)，以保證操作最大程度的獨(dú)占性。但隨之而來(lái)的就是數(shù)據(jù)庫(kù)性能的大量開(kāi)銷，特別是對(duì)長(zhǎng)事務(wù)的開(kāi)銷非常的占資源，樂(lè)觀鎖機(jī)制在一定程度上解決了這個(gè)問(wèn)題。
樂(lè)觀鎖大多是基于數(shù)據(jù)版本記錄機(jī)制實(shí)現(xiàn)，為數(shù)據(jù)增加一個(gè)版本標(biāo)識(shí)，在基于數(shù)據(jù)庫(kù)表的版本解決方案中，一般是通過(guò)為數(shù)據(jù)庫(kù)表增加一個(gè)version字段來(lái)實(shí)現(xiàn)。讀取出數(shù)據(jù)時(shí)，將此版本號(hào)一同讀出，之后更新時(shí)，對(duì)此版本號(hào)加一。此時(shí)，將提交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫(kù)表對(duì)應(yīng)記錄的當(dāng)前版本信息進(jìn)行比對(duì)，如果提交的數(shù)據(jù)版本號(hào)等于數(shù)據(jù)庫(kù)表當(dāng)前版本號(hào)，則予以更新，否則認(rèn)為是過(guò)期數(shù)據(jù)。樂(lè)觀鎖機(jī)制在高并發(fā)場(chǎng)景下，可能會(huì)導(dǎo)致大量更新失敗的操作。
樂(lè)觀鎖的實(shí)現(xiàn)是策略層面的實(shí)現(xiàn)：CAS(Compare-And-Swap)。當(dāng)多個(gè)線程嘗試使用CAS同時(shí)更新同一個(gè)變量時(shí)，只有其中一個(gè)線程能成功更新變量的值，而其它線程都失敗，失敗的線程并不會(huì)被掛起，而是被告知這次競(jìng)爭(zhēng)中失敗，并可以再次嘗試。
4、機(jī)制對(duì)比
悲觀鎖本身的實(shí)現(xiàn)機(jī)制就以損失性能為代價(jià)，多線程爭(zhēng)搶，加鎖、釋放鎖會(huì)導(dǎo)致比較多的上下文切換和調(diào)度延時(shí)，加鎖的機(jī)制會(huì)產(chǎn)生額外的開(kāi)銷，還有增加產(chǎn)生死鎖的概率，引發(fā)性能問(wèn)題。
樂(lè)觀鎖雖然會(huì)基于對(duì)比檢測(cè)的手段判斷更新的數(shù)據(jù)是否有變化，但是不確定數(shù)據(jù)是否變化完成，例如線程1讀取的數(shù)據(jù)是A1，但是線程2操作A1的值變化為A2，然后再次變化為A1，這樣線程1的任務(wù)是沒(méi)有感知的。
悲觀鎖每一次數(shù)據(jù)修改都要上鎖，效率低，寫數(shù)據(jù)失敗的概率比較低，比較適合用在寫多讀少場(chǎng)景。
樂(lè)觀鎖并未真正加鎖，效率高，寫數(shù)據(jù)失敗的概率比較高，容易發(fā)生業(yè)務(wù)形異常，比較適合用在讀多寫少場(chǎng)景。
是選擇犧牲性能，還是追求效率，要根據(jù)業(yè)務(wù)場(chǎng)景判斷，這種選擇需要依賴經(jīng)驗(yàn)判斷，不過(guò)隨著技術(shù)迭代，數(shù)據(jù)庫(kù)的效率提升，集群模式的出現(xiàn)，性能和效率還是可以兩全的。
三、Lock基礎(chǔ)案例
1、Lock方法說(shuō)明
lock：執(zhí)行一次獲取鎖，獲取后立即返回;
lockInterruptibly：在獲取鎖的過(guò)程中可以中斷;
tryLock：嘗試非阻塞獲取鎖，可以設(shè)置超時(shí)時(shí)間，如果獲取成功返回true，有利于線程的狀態(tài)監(jiān)控;
unlock：釋放鎖，清理線程狀態(tài);
newCondition：獲取等待通知組件，和當(dāng)前鎖綁定;
2、應(yīng)用案例
- import java.util.concurrent.locks.Lock;
- import java.util.concurrent.locks.ReentrantLock;
- public class LockThread02 {
- public static void main(String[] args) {
- LockNum lockNum = new LockNum() ;
- LockThread lockThread1 = new LockThread(lockNum,"TH1");
- LockThread lockThread2 = new LockThread(lockNum,"TH2");
- LockThread lockThread3 = new LockThread(lockNum,"TH3");
- lockThread1.start();
- lockThread2.start();
- lockThread3.start();
- }
- }
- class LockNum {
- private Lock lock = new ReentrantLock() ;
- public void getNum (){
- lock.lock();
- try {
- for (int i = 0 ; i < 3 ; i++){
- System.out.println("ThreadName:"+Thread.currentThread().getName()+";i="+i);
- }
- } finally {
- lock.unlock();
- }
- }
- }
- class LockThread extends Thread {
- private LockNum lockNum ;
- public LockThread (LockNum lockNum,String name){
- this.lockNum = lockNum ;
- super.setName(name);
- }
- @Override
- public void run() {
- lockNum.getNum();
- }
- }
這里多線程基于Lock鎖機(jī)制，分別依次執(zhí)行任務(wù)，這是Lock的基礎(chǔ)用法，各種API的詳解，下次再說(shuō)。
3、與synchronized對(duì)比
基于synchronized實(shí)現(xiàn)的鎖機(jī)制，安全性很高，但是一旦線程失敗，直接拋出異常，沒(méi)有清理線程狀態(tài)的機(jī)會(huì)。顯式的使用Lock語(yǔ)法，可以在finally語(yǔ)句中最終釋放鎖，維護(hù)相對(duì)正常的線程狀態(tài)，在獲取鎖的過(guò)程中，可以嘗試獲取，或者嘗試獲取鎖一段時(shí)間。
網(wǎng)站題目：Java并發(fā)編程之悲觀鎖和樂(lè)觀鎖機(jī)制
當(dāng)前URL：http://fisionsoft.com.cn/article/dhjdoog.html
