這個其實看vert.x會非常清楚
vert.x里面有兩個線程池(缺省)如果你自己不再開線程池的話
一個是eventloop線程池,還有一個是worker thread pool線程池
協程(coroutine)和纖程(fiber)的主要區別點在于:調度
這兩個單詞都翻譯得不錯,coop協作,co就是協的詞根,coroutine翻譯成協程很巧妙
fiber是纖維,翻譯成纖程,對應的thread/線程,process/進程,這幾個單詞翻譯得都比較巧妙
說回coroutine和fiber
coroutine和fiber的差異點在于,兩者的調度不一樣,異步api在結果出來前,會釋放當前線程,那么在此期間,當前線程就能去搞其他的計算活動,那一個最原始的異步api,一般是以帶有callback的形式出現,但是callback有一個問題,就是寫起來會變得混亂,因為callback要嵌套進參數里面去
如果多幾層異步調用的話,就會形成縮進金字塔
那怎么辦呢?一種解決方式就是通過聲明continuation的scope,將scope里面的所有狀態全部寄存,然后用continuation.yield釋放當前線程,然后等結果出來之后,當前線程再從寄存器里取出狀態,繼續往前執行
那這里有幾個問題,不一一列舉,有興趣的自己去搞懂這里面的機制,建議多看vert.x
有一個最重要的差別點就是,當這個結果出來之后,后續的代碼,是由哪個線程在執行?
**如果還是原來線程在執行,那么就是coroutine**
**如果存在有被其他線程所執行的可能,那就是fiber**
這里可以看出來,fiber多了一個調度器,scheduler,所以一般fiber在啟動的時候,會開一個carrier thread pool,線程池,大多數語言叫這個線程池叫做fork & join pool,既然是pool,那里面的線程不止一個,那fiber如果使用了異步操作,這里就**有可能**被一個以上的線程先后執行,注意這里是有可能,因為調度器有可能會把后續的步驟調度回原來的線程,但是這個完全由調度器決定
那這樣做的好處是什么呢?客戶在這里使用blocking code,因為這個流程基本上**完全模擬**了線程操作,線程在io時候是怎樣被blocked,這里的纖程也會怎樣被blocked
壞處是什么呢?嗯,跟線程一樣,它需要一個完美的stack,線程就有自己的stack,那這個stack可能會比線程的stack要小,但是會比coroutine的stack要大很多,同時調度上也有一定程度的消耗,當然這個消耗可能不大,但還是有,因為可能被其他線程所執行,所以要在yield之前,把當前線程的所有狀態全部寄存,否則resume的時候,狀態丟了就完蛋了
那coroutine呢?coroutine則保證會使用原來的線程,所以會有eventloop的概念,node.js就用了eventloop,還有vert.x,那因為是原來的線程,那這里會有問題,一個是線程可能過度負荷,導致一個線程在忙,其他線程在觀望的情況,所以這就出現了eventloop的一個壞處
那就是,你需要估算eventloop的執行時間,不能讓它被blocked,這就對程序員提出了更高的心智要求
好處是什么呢?性能
因為都是同一個線程在執行,那么yield的時候,需要保存的狀態就少了很多,kotlin里面一個coroutine的消耗才區區幾百個字節,一般的fiber做不到這么低
同時因為調度的都是原來的線程,所以調度的損耗也減少了,所以總體而言,coroutine+eventloop的性能,要高過fiber+fork&join pool的性能,但是同時,對開發人員的心智要求,也相應提高了
說一下java的進度,java的loom正在如火如荼地開展中,vert.x已經實現了eventloop pool,但是目前java的語法,還只能實現future(monad)和callback兩種api,還做不到await和scheduler,因為這兩者的實現,都需要project loom的continuation yield/scope和scheduler這些,但是我們已經可以在kotlin中先行體驗coroutine,其實也有fiber,用launch(common pool)加上缺省的調度器,就是fiber了
同時clojure也提供了core.async,也提供了fiber,缺省用的就是fork&join pool
所以還是要搞vert.x,否則這兩者你沒有辦法完全體驗到,像node,只有eventloop和await,沒有fiber,像go就是強制使用goroutine(就是fiber),就沒有coroutine,一般的java工具,還停留在thread階段,只有vert.x這種多語言的工具,可以提前接觸kotlin等語言,這些概念就都會出現
* * *
剛看到一個相關問題,應該說c++的boost是最早的fiber和coroutine的出處了
雖然不是java,但是java的概念也從中延伸而來,這個問題的高票答案也說到了
fiber帶了一個調度器,coroutine則不帶,java一樣的
- 基礎
- 簡介
- 主要特征
- 變量和常量
- 編碼轉換
- 數組
- byte與rune
- big
- sort接口
- 和mysql類型對應
- 函數
- 閉包
- 工作區
- 復合類型
- 指針
- 切片
- map
- 結構體
- sync.Map
- 隨機數
- 面向對象
- 匿名組合
- 方法
- 接口
- 權限
- 類型查詢
- 異常處理
- error
- panic
- recover
- 自定義錯誤
- 字符串處理
- 正則表達式
- json
- 文件操作
- os
- 文件讀寫
- 目錄
- bufio
- ioutil
- gob
- 棧幀的內存布局
- shell
- 時間處理
- time詳情
- time使用
- new和make的區別
- container
- list
- heap
- ring
- 測試
- 單元測試
- Mock依賴
- delve
- 命令
- TestMain
- path和filepath包
- log日志
- 反射
- 詳解
- plugin包
- 信號
- goto
- 協程
- 簡介
- 創建
- 協程退出
- runtime
- channel
- select
- 死鎖
- 互斥鎖
- 讀寫鎖
- 條件變量
- 嵌套
- 計算單個協程占用內存
- 執行規則
- 原子操作
- WaitGroup
- 定時器
- 對象池
- sync.once
- 網絡編程
- 分層模型
- socket
- tcp
- udp
- 服務端
- 客戶端
- 并發服務器
- Http
- 簡介
- http服務器
- http客戶端
- 爬蟲
- 平滑重啟
- context
- httptest
- 優雅中止
- web服務平滑重啟
- beego
- 安裝
- 路由器
- orm
- 單表增刪改查
- 多級表
- orm使用
- 高級查詢
- 關系查詢
- SQL查詢
- 元數據二次定義
- 控制器
- 參數解析
- 過濾器
- 數據輸出
- 表單數據驗證
- 錯誤處理
- 日志
- 模塊
- cache
- task
- 調試模塊
- config
- 部署
- 一些包
- gjson
- goredis
- collection
- sjson
- redigo
- aliyunoss
- 密碼
- 對稱加密
- 非對稱加密
- 單向散列函數
- 消息認證
- 數字簽名
- mysql優化
- 常見錯誤
- go run的錯誤
- 新手常見錯誤
- 中級錯誤
- 高級錯誤
- 常用工具
- 協程-泄露
- go env
- gometalinter代碼檢查
- go build
- go clean
- go test
- 包管理器
- go mod
- gopm
- go fmt
- pprof
- 提高編譯
- go get
- 代理
- 其他的知識
- go內存對齊
- 細節總結
- nginx路由匹配
- 一些博客
- redis為什么快
- cpu高速緩存
- 常用命令
- Go 永久阻塞的方法
- 常用技巧
- 密碼加密解密
- for 循環迭代變量
- 備注
- 垃圾回收
- 協程和纖程
- tar-gz
- 紅包算法
- 解決golang.org/x 下載失敗
- 逃逸分析
- docker
- 鏡像
- 容器
- 數據卷
- 網絡管理
- 網絡模式
- dockerfile
- docker-composer
- 微服務
- protoBuf
- GRPC
- tls
- consul
- micro
- crontab
- shell調用
- gorhill/cronexpr
- raft
- go操作etcd
- mongodb