golang監控協程,golang協程死鎖

本文目錄一覽：

• 1、最近在看golang 的 協程，一直很疑問如何開啟多個協程
• 2、Golang-基於TimeingWheel定時器
• 3、Golang 線程和協程的區別
• 4、golang channel 超時如何處理
• 5、golang協程調度模式解密

最近在看golang 的 協程，一直很疑問如何開啟多個協程

線程和C#的線程沒區別，重點在於協程。 協程Coroutine並不是多線程的，

Golang-基於TimeingWheel定時器

在linux下實現定時器主要有如下方式

在這當中 基於時間輪方式實現的定時器 時間複雜度最小，效率最高，然而我們可以通過 優先隊列 實現時間輪定時器。

優先隊列的實現可以使用最大堆和最小堆，因此在隊列中所有的數據都可以定義排序規則自動排序。我們直接通過隊列中 pop 函數獲取數據，就是我們按照自定義排序規則想要的數據。

在 Golang 中實現一個優先隊列異常簡單，在 container/head 包中已經幫我們封裝了，實現的細節，我們只需要實現特定的介面就可以。

下面是官方提供的例子

因為優先隊列底層數據結構是由二叉樹構建的，所以我們可以通過數組來保存二叉樹上的每一個節點。

改數組需要實現 Go 預先定義的介面 Len , Less , Swap , Push , Pop 和 update 。

timerType結構是定時任務抽象結構

首先的 start 函數，當創建一個 TimeingWheel 時，通過一個 goroutine 來執行 start ,在start中for循環和select來監控不同的channel的狀態

通過for循環從隊列中取數據，直到該隊列為空或者是遇見第一個當前時間比任務開始時間大的任務， append 到 expired 中。因為優先隊列中是根據 expiration 來排序的，

所以當取到第一個定時任務未到的任務時，表示該定時任務以後的任務都未到時間。

當 getExpired 函數取出隊列中要執行的任務時，當有的定時任務需要不斷執行，所以就需要判斷是否該定時任務需要重新放回優先隊列中。 isRepeat 是通過判斷任務中 interval 是否大於 0 判斷，

如果大於0 則，表示永久就生效。

防止外部濫用，阻塞定時器協程，框架又一次封裝了timer這個包，名為 timer_wapper 這個包,它提供了兩種調用方式。

參數和上面的參數一樣，只是在第三個參數中使用了任務池，將定時任務放入了任務池中。定時任務的本身執行就是一個 put 操作。

至於put以後，那就是 workers 這個包管理的了。在 worker 包中， 也就是維護了一個任務池，任務池中的任務會有序的執行，方便管理。

Golang 線程和協程的區別

線程：

多線程是為了解決CPU利用率的問題，線程則是為了減少上下文切換時的開銷，進程和線程在Linux中沒有本質區別，最大的不同就是進程有自己獨立的內存空間，而線程是共享內存空間。

在進程切換時需要轉換內存地址空間，而線程切換沒有這個動作，所以線程切換比進程切換代價要小得多。

協程：

想要簡單，又要性能高，協程就可以達到我們的目的，它是用戶視角的一種抽象，操作系統並沒有這個概念，主要思想是在用戶態實現調度演算法，用少量線程完成大量任務的調度。

Goroutine是GO語言實現的協程，其特點是在語言層面就支持，使用起來十分方便，它的核心是MPG調度模型：M即內核線程;P即處理器，用來執行Goroutine，它維護了本地可運行隊列;G即Goroutine，代碼和數據結構;S及調度器，維護M和P的信息。

golang channel 超時如何處理

個人理解的channel超時處理思路分享，若有錯誤或者不足，請聯繫我:qq 869329877

主程序通過go timeout(）掛起一個協程，在timeout方法裡面利用select來監控邏輯處理的變化，如果請求時間過長或者連接到其他服務比如grpc、mysql等服務中斷導致的請求時間過長，則直接超時，超時要返回定義的管道數據結果，否則程序會報錯。

golang協程調度模式解密

golang學習筆記

頻繁創建線程會造成不必要的開銷，所以才有了線程池。在線程池中預先保存一定數量的線程，新任務發布到任務隊列，線程池中的線程不斷地從任務隊列中取出任務並執行，可以有效的減少創建和銷毀帶來的開銷。

過多的線程會導致爭搶cpu資源，且上下文的切換的開銷變大。而工作在用戶態的協程能大大減少上下文切換的開銷。協程調度器把可運行的協程逐個調度到線程中執行，同時即時把阻塞的協程調度出協程，從而有效地避免了線程的頻繁切換，達到了少量線程實現高並發的效果。

多個協程分享操作系統分給線程的時間片，從而達到充分利用CPU的目的，協程調度器決定了則決定了協程運行的順序。每個線程同一時刻只能運行一個協程。

go調度模型包含三個實體：

每個處理器維護者一個協程G的隊列，處理器依次將協程G調度到M中執行。

每個P會周期性地查看全局隊列中是否有G待運行並將其調度到M中執行，全局隊列中的G主要來自系統調用中恢復的G.

如果協程發起系統調用，則整個工作線程M被阻塞，協程隊列中的其他協程都會阻塞。

一般情況下M的個數會略大於P個數，多出來的M將會在G產生系統調用時發揮作用。與線程池類似，Go也提供M池子。當協程G1發起系統掉用時，M1會釋放P,由 M1-P-G1 G2 … 轉變成 M1-G1 , M2會接管P的其他協程 M2-P-G2 G3 G4… 。

冗餘的M可能來源於緩存池，也可能是新建的。

當G1結束系統調用後，根據M1是否獲取到P,進行不用的處理。

多個處理P維護隊列可能不均衡，導致部分處理器非常繁忙，而其餘相對空閑。產生原因是有些協程自身不斷地派生協程。

為此Go調度器提供了工作量竊取策略，當某個處理器P沒有需要調度的協程時，將從其他處理中偷取協程，每次偷取一半。

搶佔式調度，是指避免某個協程長時間執行，而阻礙其他協程被調度的機制。

調度器監控每個協程執行時間，一旦執行時間過長且有其他協程等待，會把協程暫停，轉而調度等待的協程，以達到類似時間片輪轉的效果。比如for循環會一直佔用執行權。

在IO密集型應用，GOMAXPROCS大小設置大一些，獲取性能會更好。

IO密集型會經常發生系統調用，會有一個新的M啟用或創建，但由於Go調度器檢測M到被阻塞有一定延遲。如果P數量多，則P管理協程隊列會變小。