線程池管理(1)-爲何須要線程池

摘要

爲何須要線程池呢，沒想明白這個問題，看再多線程池的源碼都沒有用，先要知道線程池技術解決了什麼問題，才能看的懂源碼，由於全部的代碼都是爲了解決實際的工程問題。

問題

拋幾個問題，看看你是否知道，不知道的話，可能你對線程池的理解還不夠深刻，仍是隻知其一;不知其二。那麼本文會對你有用，請繼續看下去

• 線程池的線程數能夠爲1嗎？
• 線程數爲1的線程池有存在的必要嗎
• 2個有5個核心線程的線程池和1個有10個核心線程的線程池有什麼區別
• 一個應用中如何管理線程池
• 線程池池化技術和消息隊列有什麼區別

線程池原理

在大學裏咱們學習c語言時，一個main函數寫到底，就能夠交做業了。剛開始工做時，mvc一路controller -> service -> dao就OK了。可是工做中寫代碼是要解決實際問題的。你啪啪啪寫完了代碼，用戶發現你這個接口響應太慢了，怎麼辦?

用戶提交任務到程序執行完成，大體的過程如上圖，提交一個task，而後有個線程去執行。
因此要提升​程序執行的效率能夠從兩個方面來考慮

1. 異步,先響應，返回中間結果，而後異步處理，將結果返回
2. 併發，多個線程來執行。

本篇說的線程池主要就是從1的維度來提升程序執行的效率

生產者消費者模式

有必定工做經驗的朋友對消息隊列的削峯填谷，系統解耦確定不陌生。那麼線程池，算不算削峯填谷呢？
異步化後，至關於把全部的task放在了隊列中。也就是生產者 -> 容器 -> 消費者。以下圖

從圖能夠看出，線程池技術使系統複雜了，也提供了更多的靈活性。經過隊列的形式，咱們將任務的執行拆分紅了生產者，消費者模式。每一步只用關心本身的事情。若是咱們的任務很複雜，咱們能夠將任務拆分紅不一樣的步驟，每一步驟可使用不一樣的線程池來解決，以此來提升效率。

可管理性

看上去經過線程池完美解決了咱們的問題，那麼須要付出什麼代價呢？cpu的資源是有限的，線程的建立也須要代價，咱們一個java應用進程的資源是畢竟是有限的。咱們不可能在應用中無限的建立線程池。因此咱們須要管理線程池。

一般，對於簡單的應用，咱們使用一個單例線程池便可，讓應用中的全部task都使用同一個線程池，防止一些初級程序員在應用中隨意建立線程池，致使線程資源吃緊，線程佔用過多的資源。

當應用中task比較複雜的時候，咱們就須要使用分治的思想，對線程池進行隔離。
好比有些是cpu密集型的，有些是IO密集型的；任務的重要程度也有輕重之分；任務的執行時間也有不一樣。咱們須要對爲這些任務創建不一樣的線程池，以此來提升效率。

總結

線程池是一種異步化技術，經過預先建立線程/異步處理來提升響應速度。同時經過統一調配線程資源，能夠下降線程的重複建立問題，提升線程的利用率，中心化管理有利於對資源的有效控制，防止濫用。

關注【方丈的寺院】，與方丈一塊兒開始技術修行之路