為了賬號安全,請及時綁定郵箱和手機立即綁定
慕課專欄

目錄

索引目錄

Java并發編程學習寶典(漫畫版)

原價 ¥ 58.00

立即訂閱
02 絕對不僅僅是為了面試—我們為什么需要學習多線程
更新時間:2019-11-26 09:44:12
智慧,不是死的默念,而是生的沉思。

——斯賓諾莎

此時此刻,是何種原因促使你打開了本篇關于 Java 并發的專欄?實事求是地講,對于絕大多數研發人員,平時用到多線程的場景并不多。但多線程在我們的日常開發中卻無處不在,只不過很多時候,框架已經幫你實現了。比如 web 開發,容器已經幫你實現了多線程;再比如大數據開發,框架也已幫你實現了多線程,甚至分布式計算。那促使你學習多線程的原因是什么呢?我想很大可能你是為了面試打基礎、做準備。沒錯,這真的很現實!從我最近換工作的經歷來看,多線程在面試題中出現的概率幾乎是 100%。如果你想升職加薪!加入一線大廠!成為互聯網精英!多線程的知識儲備是必備的。但你想過嗎,為什么面試官熱衷于問一個平時用到并不多的技術問題?

1. 面試官考查多線程的原因

我想除了工作確實需要之外,面試官考察多線程可能有如下原因:

  1. 考察你的工作技術深度。

    多線程雖然很少用到。但是如果你做底層開發,或者負責基礎設施(例如消息隊列)研發,肯定會用到多線程。通過面試多線程,可以考察你的工作在技術方面的深度。

  2. 考察你的學習、理解能力。

    面試大概率會考多線程問題,這已經是公開的秘密了。這其實是一個開卷考試,對所有候選人是公平的。比拼的是候選人的學習能力、理解能力、做事的態度。你可以沒用過,但你要有快速掌握的能力,和穩扎穩打的學習態度。

我認為第二點是主要原因。求職者都知道面試官會考查多線程,但為什么還是有的人答非所問,有的人卻對答如流,有的人甚至可以深入底層原理?這無外乎兩個原因:

  1. 對面試的準備和態度。明知道要考察多線程,候選人卻不認真準備,這種態度帶到工作中是何其的可怕?
  2. 學習的能力。短時間內掌握平時不常用到的多線程并不容易。徹底理解多線程,還需要 JVM 的知識。這除了自身的學習能力外,如果配合一本好的教材、幾篇好的博客,能夠大大加快你的學習速度、提升你的學習深度。

生活在知識爆炸的時代,怕的不是沒有選擇,而是不知道怎么選。其實市面上關于多線程編程的書籍太多了,那為什么我還要花時間寫這個專欄呢?我在準備這個專欄前,買了 7 本多線程相關書籍。全部通讀下來后,感覺質量參差不齊。有的講得比較淺,有的講得夠深入卻晦澀難懂,而且每本書的寫法和側重點都不一樣。我寫這個專欄的目的,是想站在巨人的肩膀上,以更為通俗易懂的方式,把多線程的知識講出來。讓從來沒接觸過多線程的開發人員也能有興趣讀、能夠讀懂。并且能夠深入到底層原理,而不是蜻蜓點水。

2. 軟件世界即現實世界

再回到題目上,雖然可能絕大多數讀者是抱著提升自身實力,為面試做準備的初衷來學習多線程。但我想告訴大家,多線程真的很強大,有很多使用場景,能幫你解決很多問題。在學習完多線程后,你手中便多了一樣武器,你解決問題的思路也更為寬廣。在你以后漫漫的編程生涯中,從此多了一種選擇。所以學習多線程,絕對不是僅僅為了面試。

其實多線程并不復雜,其實和現實世界中多人協作是一樣的。編程初學者,會覺得軟件是無形的,看不見、摸不到,只有冰冷冷的邏輯,學習起來晦澀難懂。其實從面向對象出現開始,軟件已經成為現實世界的對等映射。這不光體現在語言本身,其實在軟件領域無處不在,例如:

  1. 設計模式

    23 種經典設計模式,沒有哪一種不是從現實世界得來的靈感。如果你看過設計模式的文章,你一定對設計模式中生動有趣的例子所吸引。

  2. 軟件設計

    絕大多數軟件的設計,都參考了工業設計或者參考了生活中解決問題的方式,汲取其中的設計思想。其實不管軟件還是硬件或者生活中遇到的難題,在解決問題的思路上是一致的。無形的軟件設計,可以借助有形世界里的案例來幫助你思考。我最近在看 kafka 的源代碼,其中 producer 的設計思想和快遞公司發快遞的過程很類似。還有 Java NIO,也是類似的原理??梢哉f軟件設計的思想都發源于現實世界。

  3. 軟件架構

    我做個類比,軟件架構可以看作現實世界工廠里的機器設計和布置。我們需要考慮很多,比如需要哪些機器,不同機器如何配比、不同工序之間如何銜接、機器出問題如何應對、機器操作日志如何記錄、安全如何保障。工廠里遇到的問題在軟件架構上也都會遇到。

以上舉例,足以說明軟件和現實世界之間的相似程度。軟件其實就是現實世界的映射。我們在學習軟件的過程中,要善于找到生活中常見的例子類比,這樣理解起來就沒有困難了,而且便于記憶。

3. 多線程典型應用場景

啰嗦了這么多,主要是為了介紹我在編程上面的學習心得,希望能對大家有些幫助。下面我們就來看看多線程的幾種典型應用場景,以下例子都由現實世界的場景切入講解。在現實世界中,我們可以認為每個人都是一個線程,當多個人一起完成一項工作,這其實就是多線程。我們來看下面的多線程場景:

  1. 工作量太大,需要多人一塊干,以縮短工期

    這種場景在現實生活中比比皆是,比如要完成書稿校對工作。顯然一個人校對太慢了,那就多叫幾個人吧!每個人分一個章節,同時進行校對,速度一下就上來了。如下圖所示:
    圖片描述編程上,如果程序需要重復執行一段邏輯,每次執行又互不影響,那么你可以考慮采用多線程,每個線程執行任務總量的一部分,最后再把每個線程執行的結果合并。通過并行處理,能夠大大減少執行時間。Java 8 開始出現的 lambda 并行流,就是采用的這種思想,只不過它是 JVM 去實現,而不需要我們做額外的處理。另外在大數據領域,對于海量數據的處理,也可以采用多線程,縮短執行時間。

  2. 實現分工

    這個場景的例子也很多,而且很貼近我們的生活。例如,我們每天中午都會去吃工作餐,飯館的工作流程大同小異,如下圖所示: 圖片描述飯店會有這么幾類員工,收銀員、廚師、傳菜員、清潔員。每個人各司其職,大家配合工作。飯店的工作流程如下:

    1、顧客在收款臺點單;

    2、后廚接到系統傳過來的訂單后開始加工;

    3、做好飯菜后傳菜員取飯菜;

    4、傳菜員找到客戶所在位置上菜;

    5、顧客用餐后,清潔員進行打掃。

    每種角色的員工只關心自己的輸入和輸出。比如廚師的輸入就是客戶的點菜單,輸出就是飯菜。而廚師的輸入則是上個環節收銀員的輸出。這樣做的好處是每個人專注于自己的工作,有助于效率的提升。其實好處還很多,我總結如下:

    • 每種角色對應一個環節,每個環節在執行上獨立分開。這樣每個環節的工作就解耦了;
    • 每個環節之間有了緩沖。收銀員一直在收銀,她不需要知道廚師是否空閑,她在不停輸出訂單。而廚師接到訂單就去加工,而不關心積累了多少訂單,只要一份菜接一份菜的去加工。訂單的列表就是一個緩沖,調節兩個環節速率的不匹配及不穩定。如果一個人干所有的事情,那么問題就來了。舉個反面的例子,某著名連鎖便利店,在早餐時段,收銀員即收銀又負責做咖啡并配餐,結果導致整個收銀的隊伍相當的長。我即使只買個面包,也要排隊很久;
    • 每種角色只做自己的事情,省去了上下文切換的時間。如果你一個人干所有的事情,當你為顧客下單完成后,要跑去后廚炒菜,再端給客戶,然后再回到收銀臺為下一位顧客下單。單單是浪費在路上的時間就會有多少??!而且每次切換工作,你都要在腦海里想一下接下來的這個工作需要怎么做;
    • 我們看下清潔員這個角色。他看到有人吃完飯離開就會去收拾桌子。假如沒有分工,而是一個人干所有的工作,那么餐廳員工給客人端上飯菜后,還要一直等到客戶吃完飯,才能收拾桌子,效率何其低下。我想沒有老板傻到會讓自己的員工如此工作;
    • 便于對原有流程進行改變。假如老板想在點餐前,增加向客戶推銷關注店鋪公眾號,并注冊會員的環節。如果沒有分工,老板要向所有員工通知這個事情,并且組織所有人學習。但是有了分工后,只有收銀員需要進行學習。而其他角色的員工完全不需要知道這件事情。老板是不是輕松多了?

    通過分工,多人協作,餐廳的工作才能高效運轉起來。我們開發的程序也是如此,如果你所有的工作都在一個線程里,那么首先這段主邏輯會相當復雜,而且難于維護和擴展,另外相信效率也會相對低下。如果我們的程序通過多線程 + 緩沖的方式,把不同步驟解耦,那么將大大提高效率。

    還是拿 kafka 舉例,Kafka 的 producer 發送消息的機制就是如此,首先不同的發消息線程會往緩存中累積消息,此時消息沒有被真正發送出去,只是累積在本地緩存中。Kafka 有專門負責網絡 IO 的 sender 線程,當緩存滿了,sender 線程被喚醒,它真正把消息發送出去,而此時新的消息還會被累積進來。

    Kafka 的這種多線程設計,使得收集消息和 IO 發送消息解耦。sender 線程可以根據消息發往主機的不同,把消息分類打包,一次網絡 IO 可以發送出多條消息,從而大大減少了網絡 IO 的消耗。

    我們再想想清潔員所做的工作,是不是很熟悉?沒錯,其實 JVM 中的 GC 線程就相當于清潔員。

  3. 分頭行動,最后匯合

    這也是分工協作的一種,只不過是分頭行動后,大家要把行動的結果匯總,才能執行接下來的任務。接下來這個例子,作為研發同學再熟悉不過了?,F在 BS 軟件開發,前后端分離已經成為了趨勢,在這種開發方式下,一般分為三步:

    1、前、后端研發定義接口;

    2、前、后端開發分頭開發;

    3、前、后端聯調。

    第 3 步的前提是第 2 步。在第 2 步中,前后端程序員分頭進行開發,誰先開發完都沒有用,只有二者都開發完了,才能進入第三步。

    在微服務大行其道的時代,類似上面這種場景的多線程應用很常見。例如,你的一個業務接口中,可能會調用數個微服務接口獲取數據。如果你沒有采用多線程,那么每次請求時,主線程都會被阻塞。但是假如你采用了多線程開發,對微服務的幾個請求可以同時發出,主線程阻塞時間只取決于幾個請求中最長的那個,而不是所有請求阻塞時間之和,這樣會極大地提高響應速度。

  4. 排隊的同時,不耽誤做其他事情

    我平時很討厭排隊,所以看到做什么事情要排隊,我就放棄了,因為排隊給我的感覺就是在浪費時間,什么都做不了。當然,在移動互聯網時代,排隊時刷刷手機還是可以的。有沒有一種方式,能讓我把隊排了,但不耽誤我做別的事情呢?當然有,我舉個例子。我們都應該做過體檢,檢查項目中最慢的就是 B 超。我說過我最不愛排隊,所以我都是最后才去做 B 超,但每次還是要排隊半個小時以上。近幾年我去體檢時,發現流程優化了。你先去 B 超排個號,然后可以先去做其他項目的檢查,當你聽到叫號你所在的區間時,再去做 B 超。這個流程改進只需要添加一個要素,就是發你一個號碼。拿到你的序號牌后,你可以去做其他事情。等叫到你的號,你可以憑號進行 B 超檢查。

    這其實就是 java 多線程中的 Future 模式。這種模式下,主線程不會因為一個耗時的業務操作而被阻塞住,主線程可以單起一個線程去處理耗時的操作,主線程邏輯繼續執行,等用到另外線程返回的數據時,再通過 Futrue 對象獲取。Future 就是你的一張舊船票,你憑借這張舊船票,還能登上那艘客船。

4. 總結

本節我們了解了多線程的應用場景。其實除了文中列舉的,還有許多其它使用多線程的場景?,F實世界中幾乎所有的工作都需要多人協作,而計算機的世界亦是如此。了解完多線程各種應用場景,下面就讓我們開啟 Java 多線程的學習之旅吧!

}
立即訂閱 ¥ 58.00

你正在閱讀課程試讀內容,訂閱后解鎖課程全部內容

千學不如一看,千看不如一練

手機
閱讀

掃一掃 手機閱讀

Java并發編程學習寶典(漫畫版)
立即訂閱 ¥ 58.00

舉報

0/150
提交
取消
开奖号码