<sub id="gqw76"><listing id="gqw76"></listing></sub>
      <sub id="gqw76"><listing id="gqw76"></listing></sub>

    1. <form id="gqw76"><legend id="gqw76"></legend></form>
    2. 圖解 | 原來這就是線程池

      小宇:閃客,我最近看到線程池,被里邊亂七八槽的參數給搞暈了,你能不能給我講講呀?

      閃客:沒問題,這個我擅長,咱們從一個最簡單的情況開始,假設有一段代碼,你希望異步執行它,是不是要寫出這樣的代碼?

      new Thread(r).start();

        小宇:嗯嗯,最簡單的寫法似乎就是這樣呢。

      閃客:這種寫法當然可以完成功能,可是你這樣寫,老王這樣寫,老張也這樣寫,程序中到處都是這樣創建線程的方法,能不能寫一個統一的工具類讓大家調用呢?

      小宇:可以的,感覺有一個統一的工具類,更優雅一些。

      閃客:那如果讓你來設計這個工具類,你會怎么寫呢?我先給你定一個接口,你來實現。

      public interface Executor {
          public void execute(Runnable r);
      }

      小宇:emmm,我可能先定義幾個成員變量,比如核心線程數、最大線程數 ...反正就是那些亂七八糟的參數。

      閃客:STOP!小宇呀,你現在深受面試手冊的毒害,你先把這些全部的概念忘掉,就說讓你寫一個最簡單的工具類,第一反應,你會怎么寫?

       

      第一版

      小宇:那我可能會這樣

      // 新線程:直接創建一個新線程運行
      class FlashExecutor implements Executor {
          public void execute(Runnable r) {
              new Thread(r).start();
          }
      }
      

        閃客:嗯嗯很好,你的思路非常棒。

      小宇:啊,我這個會不會太 low 了呀,我還以為你會罵我呢。

      怎么會, Doug Lea 大神在 JDK 源碼注釋中給出的就是這樣的例子,這是最根本的功能。你在這個基礎上,嘗試著優化一下?

       

      第二版

      小宇:還能怎么優化呢?這不已經用一個工具類實現了異步執行了嘛!

      閃客:我問你一個問題,假如有 10000 個人都調用這個工具類提交任務,那就會創建 10000 個線程來執行,這肯定不合適吧!能不能控制一下線程的數量呢?

      小宇:這不難,我可以把這個任務 r 丟到一個 tasks 隊列中,然后只啟動一個線程,就叫它 Worker 線程吧,不斷從 tasks 隊列中取任務,執行任務。這樣無論調用者調用多少次,永遠就只有一個 Worker 線程在運行,像這樣。

      閃客:太棒了,這個設計有了三個重大的意義:

      1. 控制了線程數量。

      2. 隊列不但起到了緩沖的作用,還將任務的提交與執行解耦了。

      3. 最重要的一點是,解決了每次重復創建和銷毀線程帶來的系統開銷。

      小宇:哇真的么,這么小的改動有這么多意義呀。

      閃客:那當然,不過只有一個后臺的工作線程 Worker 會不會少了點?還有如果這個 tasks 隊列滿了怎么辦呢?

       

      第三版

      小宇:哦,的確,只有一個線程在某些場景下是很吃力的,那我把 Worker 線程的數量增加?

      閃客:沒錯,Worker 線程的數量要增加,但是具體數量要讓使用者決定,調用時傳入,就叫核心線程數 corePoolSize 吧。

      小宇:好的,那我這樣設計。

      1. 初始化線程池時,直接啟動 corePoolSize 個工作線程 Worker 先跑著。

      2. 這些 Worker 就是死循環從隊列里取任務然后執行。

      3. execute 方法仍然是直接把任務放到隊列,但隊列滿了之后直接拋棄

      閃客:太完美了,獎勵你一塊費列羅吧。

      小宇:哈哈謝謝,那我先吃一會兒哈。 

      閃客:好,你邊吃我邊說。現在我們已經實現了一個至少不那么丑陋的線程池了,但還有幾處小瑕疵,比如初始化的時候,就創建了一堆 Worker 線程在那空跑著,假如此時并沒有異步任務提交過來執行,這就有點浪費了。

      小宇:哦好像是誒!

      閃客:還有,你這隊列一滿,就直接把新任務丟棄了,這樣有些粗暴,能不能讓調用者自己決定該怎么處理呢?

      小宇:哎呀,想不到我這么溫柔的妹紙居然寫出了這么粗暴的代碼。

      閃客:額,你先把費列羅咽下去吧。

       

      第四版

      小宇:我吃完了,現在腦子有點不夠用了,得先消化消化食物,要不你幫我分析分析吧。

      閃客:好的,現在我們做出如下改進。

      1. 按需創建Worker:剛初始化線程池時,不再立刻創建 corePoolSize 個工作線程,而是等待調用者不斷提交任務的過程中,逐漸把工作線程 Worker 創建出來,等數量達到 corePoolSize 時就停止,把任務直接丟到隊列里。那就必然要用一個屬性記錄已經創建出來的工作線程數量,就叫 workCount 吧。

      2. 加拒絕策略:實現上就是增加一個入參,類型是一個接口 RejectedExecutionHandler,由調用者決定實現類,以便在任務提交失敗后執行 rejectedExecution 方法。

      3. 增加線程工廠:實現上就是增加一個入參,類型是一個接口 ThreadFactory,增加工作線程時不再直接 new 線程,而是調用這個由調用者傳入的 ThreadFactory 實現類的 newThread 方法。

      就像下面這樣。

      小宇:哇,還是你厲害,這一版應該很完美了吧? 閃客:不不不,離完美還差得很遠,接下來的改進,由你來想吧,我這里可以給你一個提示

      彈性思維


      第五版

      小宇:彈性思維?哈哈閃客你這術語說的真是越來越不像人話了

      閃客:咳咳

      小宇:哦,我是說你肯定是指我這個代碼寫的沒有彈性,對吧?可是彈性是指什么呢?

      閃客:簡單說,在這個場景里,彈性就是在任務提交比較頻繁,和任務提交非常不頻繁這兩種情況下,你這個代碼是否有問題?

      小宇:emmm 讓我想想,我這個線程池,當提交任務的量突增時,工作線程和隊列都被占滿了,就只能走拒絕策略,其實就是被丟棄掉

      閃客:是的

      小宇:這樣的確是太硬了,誒不過我想了下,調用方可以通過設置很大的核心線程數 corePoolSize 來解決這個問題呀。

      閃客:的確是可以,但一般場景下 QPS 高峰期都很短,而為了這個很短暫的高峰,設置很大的核心線程數,簡直太浪費資源了,你看上面的圖不覺得眼暈么?

      小宇:是呀,那怎么辦呢,太大了也不行,太小了也不行。

      閃客:我們可以發明一個新的屬性,叫最大線程數 maximumPoolSize 。當核心線程數和隊列都滿了時,新提交的任務仍然可以通過創建新的工作線程(叫它 非核心線程 ),直到工作線程數達到 maximumPoolSize 為止,這樣就可以緩解一時的高峰期了,而用戶也不用設置過大的核心線程數。

      小宇:哦好像有點感覺了,可是具體怎么操作呢? 閃客:想象力不行呀小宇,那你看下面的演示。

      1. 開始的時候和上一版一樣,當 workCount < corePoolSize 時,通過創建新的 Worker 來執行任務。

      2. 當 workCount >= corePoolSize 就停止創建新線程,把任務直接丟到隊列里。

      3. 但當隊列已滿且仍然 workCount < maximumPoolSize 時,不再直接走拒絕策略,而是創建非核心線程,直到 workCount = maximumPoolSize,再走拒絕策略。

      小宇:哎呀,我怎么沒想到,這樣 corePoolSize 就負責平時大多數情況所需要的工作線程數,而 maximumPoolSize 就負責在高峰期臨時擴充工作線程數。

      閃客:沒錯,高峰時期的彈性搞定了,那自然就還要考慮低谷時期。當長時間沒有任務提交時,核心線程與非核心線程都一直空跑著,浪費資源。我們可以給非核心線程設定一個超時時間 keepAliveTime ,當這么長時間沒能從隊列里獲取任務時,就不再等了,銷毀線程。

      小宇:嗯,這回咱們的線程池在 QPS 高峰時可以臨時擴容,QPS 低谷時又可以及時回收線程(非核心線程)而不至于浪費資源,真的顯得十分 Q 彈呢。

      閃客:是呀是呀。誒不對,怎么又變成我說了,不是說這一版你來思考么?

      小宇:我也想啊,但你這一講技術就自說自話的毛病老是不改,我有啥辦法。 閃客:額抱歉抱歉,那接下來你總結一下我們的線程池吧

       

      總結

      小宇:嗯好的,首先它的構造方法是這個樣子滴

       

      public FlashExecutor(
              int corePoolSize,
              int maximumPoolSize,
              long keepAliveTime,
              TimeUnit unit,
              BlockingQueue<Runnable> workQueue,
              ThreadFactory threadFactory,
              RejectedExecutionHandler handler) 
      {
          ... // 省略一些參數校驗
          this.corePoolSize = corePoolSize;
          this.maximumPoolSize = maximumPoolSize;
          this.workQueue = workQueue;
          this.keepAliveTime = unit.toNanos(keepAliveTime);
          this.threadFactory = threadFactory;
          this.handler = handler;
      }

       

      這些參數分別是

      int corePoolSize:核心線程數

      int maximumPoolSize:最大線程數

      long keepAliveTime:非核心線程的空閑時間

      TimeUnit unit:空閑時間的單位

      BlockingQueue<Runnable> workQueue:任務隊列(線程安全的阻塞隊列)

      ThreadFactory threadFactory:線程工廠

      RejectedExecutionHandler handler:拒絕策略

      整個任務的提交流程是

      閃客:不錯不錯,這可是你自己總結的喲,現在還用我給你講什么是線程池了么?

      小宇:啊天呢,我才發現這似乎就是我一直弄不清楚的線程池的參數和原理呢!

      閃客:沒錯,而且最后一版代碼的構造方法,就是 Java 面試常考的  ThreadPoolExecutor 最長的那個構造方法,參數名都沒變。

      小宇:哇,太贊了!我都忘了一開始我想干嘛了,嘻嘻。

      閃客:哈哈,不知不覺學到了技術才爽呢,對吧?晚飯時間快到了,要不要一塊去吃山西面館呀?

      小宇:哦,那家店餐桌的顏色我不太喜歡,下次吧。

      閃客:哦好吧。

      后記


      線程池是面試常考的知識點,網上很多文章都是直接從它那有 7 個參數的構造方法講起,強行把各個參數的含義說給你聽,讓人云里霧里。 希望讀者讀完本篇文章后,線程池的這些參數不再是死記硬背,而是像本文中這些動圖一樣在你的腦中活靈活現,這樣就能永遠記住他們啦~ 本文中各個版本都有對應代碼,在公眾號 低并發編程 后臺回復 線程池 即可獲取。

      posted @ 2021-02-03 19:30  閃客sun  閱讀(4507)  評論(25編輯  收藏
      最新chease0ldman老人|无码亚洲人妻下载|大香蕉在线看好吊妞视频这里有精品www|亚洲色情综合网

        <sub id="gqw76"><listing id="gqw76"></listing></sub>
        <sub id="gqw76"><listing id="gqw76"></listing></sub>

      1. <form id="gqw76"><legend id="gqw76"></legend></form>