併發程式設計一直是Java基礎中的高地，但很多隻要有兩三年Java基礎的工程師，會在簡歷中很明確的標明“熟悉多執行緒程式設計、有高併發程式設計經驗”，來凸顯自己程式設計能力有多厲害，但實際上可能只是看了《Java Concurrency in Practice》的幾個章節而已。其實對很多業務研發工程師來說，高併發程式設計經驗並不是必備的核心競爭力之一，很多需要加鎖或者統計的場景，大都可以交給外部系統如Redis來做，即多執行緒併發場景的轉移。
那麼作為面試官，如何簡單快速考察面試者的多執行緒程式設計能力？可能方法有很多，筆者喜歡用到的一個題目如下：“對於單個Java應用，我們如何限制其中某個方法methodA()被呼叫的併發數不能超過100，如果超過100，超出的請求就直接返回null或拋異常”。筆者會要求面試者在白板上寫出相應程式碼片段（當然並不會要求面試者一定要完整寫出用到的類名或方法名）。
這個題看起來並不難，但仔細想想也不那麼簡單，大約30%的面試者會給出Semaphore的解決方案，例如：

    private static Semaphore semaphore = new Semaphore(100);

    public static Integer methodA() {
        if(!semaphore.tryAcquire()) {
            return null;
        }

        try {
        // TODO 方法中的業務邏輯
        } finally {
            semaphore.release();
        }
    }

Semaphore訊號量是一種比較完美的解決方案，程式碼簡單而高效，一旦面試者給出這個方案，我們可以順便考察下訊號量相關的知識點。

但還有沒有其他的思路或解決方案呢？筆者接觸到的面試者，還給出過執行緒池的方案，因為最高併發數是100，那麼表明同時最多隻能有100個執行緒訪問該方法，面試者一般會這麼寫：

    private final static ExecutorService pool = new ThreadPoolExecutor(100, 100, 1, TimeUnit.MINUTES, new SynchronousQueue<>());

    public static Integer methodAWrapper() {
        try {
            Future<Integer> future = pool.submit(() -> methodA());
            return future.get();
        } catch (Exception e) {
          return null;
        }
    }

    public static Integer methodA() {
        // TODO 方法中的業務邏輯
    }
 

其實嚴格意義來講，執行緒池的這種方案無法完美做到“如果超過100，超出的請求就直接返回null或拋異常”，哪怕是使用SynchronousQueue佇列。但沒關係，最關鍵的考察點並不在超限如何返回。當面試者寫出這種方案，也可以順便考察下執行緒池相關的知識點。
大多數面試者想到的是寫個計數器，例如：

    private static AtomicInteger counter = new AtomicInteger(0);

    public static Integer methodA() {

        int value = counter.incrementAndGet();
        if(value > 100) {
            return null;
        }

        try {
            // TODO 方法中的業務邏輯
        } finally {
            counter.decrementAndGet();
        }
    }

於是我一般會問，為啥是選擇incrementAndGet方法，而不是選擇getAndIncrement？仔細看看會不會有其他問題？大多數面試者經過提示都能發現這裡get、incr和比較不是原子操作，會產生“競態條件”（race condition）。我們先把這種計數器方案叫做方案A，像想到計數器方案的面試者，也有小部分會這樣寫：

    private static AtomicInteger counter = new AtomicInteger(0);

    public static Integer methodA() {

        int value = counter.get();
        if(value > 100) {
            return null;
        }
        
        counter.incrementAndGet();

        try {
            // TODO 方法中的業務邏輯
        } finally {
            counter.decrementAndGet();
        }
    }

我們把這種計數器的實現方案叫做方案B，這兩種方案都會有“競態條件”的問題，但產生的現象不一樣。

對於方案A，在極端高併發的情況下，每個呼叫methodA的請求，都會對計數器進行+1，即使我們在finally對計數器進行了-1，也阻止value的值繼續上漲，導致遠大於100，得到的結果是所有請求沒機會執行業務邏輯，即“餓死”現象。

對於方案B，由於是活的執行業務邏輯的許可後再進行的+1操作，很顯然在高併發情況下會導致執行業務邏輯的執行緒數超過100。

很多Java老司機覺得自己不會犯這種錯誤，但實際上，最近阿里的開源專案Sentinel就有類似方案A的問題，Sentinel中使用責任鏈的模式，來對每筆呼叫進行統計、攔截，這裡給出構建責任鏈DefaultSlotsChainBuilder類的程式碼片段：

public class DefaultSlotsChainBuilder implements SlotsChainBuilder {

    @Override
    public ProcessorSlotChain build() {
        ProcessorSlotChain chain = new DefaultProcessorSlotChain();
        chain.addLast(new NodeSelectorSlot());
        chain.addLast(new ClusterBuilderSlot());
        chain.addLast(new LogSlot());
        chain.addLast(new StatisticSlot()); // 統計資料，類似於上文提到的incrementAndGet
        chain.addLast(new SystemSlot());    // 檢查是否超過閾值，類似於上文提到的value > 100
        chain.addLast(new AuthoritySlot());
        chain.addLast(new FlowSlot());
        chain.addLast(new DegradeSlot());

        return chain;
    }
}

而在分散式服務框架Dubbo的早期版本（例如2.5.3），在對Provider提供執行緒限制保護的executes
（例如：<dubbo:service interface="com.manzhizhen.dubbo.server.service.Dubbo2Service"
ref="dubbo2Service" version="1.0.0" timeout="3000" executes="10" />）的實現方案，就踩了上述方案B的坑。

迴歸正題，也有面試者給出了阻塞佇列的方案，即：

    private static BlockingQueue<Integer> reqQueue = new ArrayBlockingQueue<>(100);

    public static Integer methodA() {

        if(!reqQueue.offer()) {
            return null;
        }

        try {
            // TODO 方法中的業務邏輯
        } finally {
            reqQueue.poll();
        }
    }

阻塞佇列的方案也是不錯的，程式碼簡單，效率也還行。

當然，也有面試者說用Hystrix，嗯嗯，這也是可以的。

做個總結吧，最優方案當然是使用Semaphore，但Semaphore無法統計實際高峰期時的併發量有多少（很多場景需要通過實際最高的併發值來優化我們系統），文章很短，希望對大家能有所幫助。