1. 程式人生 > >Java併發程式設計學習記錄#2

Java併發程式設計學習記錄#2

執行緒安全篇B

為了保持狀態的一致性,需要在一個原子性操作中更新相關的狀態變數,加鎖,可以將一些混合操作變為原子性操作,從而保證執行緒安全。

1.內部鎖

Java提供了一個加強原子性的內在鎖機理-同步塊,其包含兩部分,一部分是一個可以作為鎖的物件的引用,另一部分是由這個鎖保護的阻塞程式碼。同步方法是同步塊的一個快捷體現,其作用於所有的方法體。

每一個Java物件都可以作為一個潛在的同步鎖,這種內部構建的鎖叫做內部鎖或是管程鎖。當執行緒進入同步塊前會自動獲得鎖,並在執行退出(正常或異常的情況)後,自動釋放鎖。

內在鎖是一種互斥鎖,即至多有一個執行緒可以擁有鎖。當執行緒A想要獲得執行緒B獲得的鎖,它必須等待或者阻塞,直到B執行緒釋放鎖,若不釋放,A會一直等待。

2.重入性

重入性指的是鎖的獲得基於每個執行緒,而不是基於每次呼叫;一個執行緒可以成功請求獲得它已經持有的鎖;

該特性的實現是因為鎖的請求獲得次數(lockcount)和持有它的執行緒的關聯來實現的。當一個執行緒獲得或者再次獲得鎖時,在虛擬機器裡將會lockcount+1,當一個同步塊退出時,虛擬機器會讓lockcount-1。當lockcount=0時,該執行緒釋放鎖。

重入性簡化了面向物件的併發操作,否則的話,像如下程式碼中,將會發生死鎖。

public class Widget {
    public synchronized void doSomething() {
        ...
    }
}
public
class LoggingWidget extends Widget { public synchronized void doSomething() { System.out.println(toString() + ": calling doSomething"); super.doSomething(); } }

用鎖保護狀態

由於鎖可以將對程式碼的訪問變得序列化,因此可以使用鎖來構建一些策略來保障共享狀態的排他性。

一個可以被多個執行緒訪問的可變狀態,所有的訪問都需要持有共同的鎖,此時,我們稱這個狀態被這個鎖保護。

物件的內部鎖和它的狀態沒有內在的關聯,一個物件的成員不會自動被其內部鎖保護。獲得一個物件的內部鎖,僅僅會阻止其它執行緒獲得這個鎖,但並不妨礙其它執行緒訪問這個物件。

每次共享時,一個可變狀態需要指定一個具體的鎖,並使其使用者知道是哪個鎖。

對於每一個擁有多於一個變數的不變數來說,它的所有變數應該使用同一個鎖來保護。

一個通用的鎖策略是,將所有可變狀態用一個物件封裝起來,然後所有訪問這些可變狀態的程式碼都用這個物件的內部鎖保護起來,用來防止併發訪問。這種方式很常用,也很簡單,但是這樣會導致活性和效能問題。

活性和效能

不合適的同步,特別是同步耗時操作,會使得併發能力下降,甚至失去併發能力。

用兩段程式碼解釋更直觀。

  • 粗糙同步,省略了一些次要程式碼。Servlet框架的設計本意是同時處理多個請求,但是同步後的service方法一旦有耗時操作,那麼由於同步的原因,其它的請求只能等上一個請求完成之後才能進行,降低了處理效能。
public class SynchronizedFactorizer extends GenericServlet implements Servlet {
    @GuardedBy("this") private BigInteger lastNumber;
    @GuardedBy("this") private BigInteger[] lastFactors;

    public synchronized void service(ServletRequest req,
                                     ServletResponse resp) {
        BigInteger i = extractFromRequest(req);
        if (i.equals(lastNumber))
            encodeIntoResponse(resp, lastFactors);
        else {
            BigInteger[] factors = factor(i);
            lastNumber = i;
            lastFactors = factors;
            encodeIntoResponse(resp, factors);
        }
    }

    void encodeIntoResponse(ServletResponse resp, BigInteger[] factors) {
    }

    BigInteger extractFromRequest(ServletRequest req) {
        return new BigInteger("7");
    }

    BigInteger[] factor(BigInteger i) {
        // Doesn't really factor
        return new BigInteger[] { i };
    }
}
  • 精細同步,只需進行精緻的分割,改變同步的位置,便能儘可能的消除加鎖對效能帶來的影響。見程式碼:
public class CachedFactorizer extends GenericServlet implements Servlet {
    @GuardedBy("this") private BigInteger lastNumber;
    @GuardedBy("this") private BigInteger[] lastFactors;
    @GuardedBy("this") private long hits;
    @GuardedBy("this") private long cacheHits;

    public synchronized long getHits() {
        return hits;
    }

    public synchronized double getCacheHitRatio() {
        return (double) cacheHits / (double) hits;
    }

    public void service(ServletRequest req, ServletResponse resp) {
        BigInteger i = extractFromRequest(req);
        BigInteger[] factors = null;
        synchronized (this) {
            ++hits;
            if (i.equals(lastNumber)) {
                ++cacheHits;
                factors = lastFactors.clone();
            }
        }
        if (factors == null) {
            factors = factor(i);
            synchronized (this) {
                lastNumber = i;
                lastFactors = factors.clone();
            }
        }
        encodeIntoResponse(resp, factors);
    }

    void encodeIntoResponse(ServletResponse resp, BigInteger[] factors) {
    }

    BigInteger extractFromRequest(ServletRequest req) {
        return new BigInteger("7");
    }

    BigInteger[] factor(BigInteger i) {
        // Doesn't really factor
        return new BigInteger[]{i};
    }
}

如何確定同步塊的大小需要考慮安全性,易用性和效能。有時候,易用性和效能是一對相對矛盾的設計指標。無論何時在使用鎖時,應該考慮到被同步的程式碼能做什麼,以及這些程式碼耗時大概多少。進行大量的計算或是存在潛在的阻塞操作,都有可能加長持有鎖的時間,進一步影響到程式的活性和效能。

涉及大量計算和耗時操作(如net或者io)的程式碼,應避免持有鎖。

//待下篇

主要參考自_ Java Concurrency in Practice