hello，大家好呀，我是既寫 Java 又寫 Go 的小樓，在寫 Go 的程序中經常對比這兩種語言的特性，踩了不少坑，也發現了不少有意思的地方，今天就來聊聊 Go 自帶的 HttpClient 的超時機制，
Java HttpClient 超時底層原理
在介紹 Go 的 HttpClient 超時機制之前，我們先看看 Java 是如何實作超時的，
寫一個 Java 原生的 HttpClient，設定連接超時、讀取超時時間分別對應到底層的方法分別是：
再追溯到 JVM 原始碼，發現是對系統呼叫的封裝，其實不光是 Java，大部分的編程語言都借助了作業系統提供的超時能力，
然而 Go 的 HttpClient 卻提供了另一種超時機制，挺有意思，我們來盤一盤，但在開始之前，我們先了解一下 Go 的 Context，
Go Context 簡介
Context 是什么？
根據 Go 原始碼的注釋：
// A Context carries a deadline, a cancellation signal, and other values across
// API boundaries.
// Context's methods may be called by multiple goroutines simultaneously.
Context 簡單來說是一個可以攜帶超時時間、取消信號和其他資料的介面，Context 的方法會被多個協程同時呼叫，
Context 有點類似 Java 的ThreadLocal，可以在執行緒中傳遞資料，但又不完全相同，它是顯示傳遞，ThreadLocal 是隱式傳遞，除了傳遞資料之外，Context 還能攜帶超時時間、取消信號，
Context 只是定義了介面，具體的實作在 Go 中提供了幾個：
- Background ：空的實作，啥也沒做
- TODO：還不知道用什么 Context，先用 TODO 代替，也是啥也沒做的空 Context
- cancelCtx：可以取消的 Context
- timerCtx：主動超時的 Context
針對 Context 的三個特性，可以通過 Go 提供的 Context 實作以及原始碼中的例子來進一步了解下，
Context 三個特性例子
這部分的例子來源于 Go 的原始碼，位于 src/context/example_test.go
攜帶資料
使用 context.WithValue 來攜帶，使用 Value 來取值，原始碼中的例子如下：
// 來自 src/context/example_test.go
func ExampleWithValue() {
type favContextKey string
f := func(ctx context.Context, k favContextKey) {
if v := ctx.Value(k); v != nil {
fmt.Println("found value:", v)
return
}
fmt.Println("key not found:", k)
}
k := favContextKey("language")
ctx := context.WithValue(context.Background(), k, "Go")
f(ctx, k)
f(ctx, favContextKey("color"))
// Output:
// found value: Go
// key not found: color
}
取消
先起一個協程執行一個死回圈，不停地往 channel 中寫資料，同時監聽 ctx.Done() 的事件
// 來自 src/context/example_test.go
gen := func(ctx context.Context) <-chan int {
dst := make(chan int)
n := 1
go func() {
for {
select {
case <-ctx.Done():
return // returning not to leak the goroutine
case dst <- n:
n++
}
}
}()
return dst
}
然后通過 context.WithCancel 生成一個可取消的 Context，傳入 gen 方法，直到 gen 回傳 5 時，呼叫 cancel 取消 gen 方法的執行，
// 來自 src/context/example_test.go
ctx, cancel := context.WithCancel(context.Background())
defer cancel() // cancel when we are finished consuming integers
for n := range gen(ctx) {
fmt.Println(n)
if n == 5 {
break
}
}
// Output:
// 1
// 2
// 3
// 4
// 5
這么看起來，可以簡單理解為在一個協程的回圈中埋入結束標志，另一個協程去設定這個結束標志，
超時
有了 cancel 的鋪墊，超時就好理解了，cancel 是手動取消，超時是自動取消，只要起一個定時的協程，到時間后執行 cancel 即可，
設定超時時間有2種方式：context.WithTimeout 與 context.WithDeadline，WithTimeout 是設定一段時間后，WithDeadline 是設定一個截止時間點，WithTimeout 最終也會轉換為 WithDeadline，
// 來自 src/context/example_test.go
func ExampleWithTimeout() {
// Pass a context with a timeout to tell a blocking function that it
// should abandon its work after the timeout elapses.
ctx, cancel := context.WithTimeout(context.Background(), shortDuration)
defer cancel()
select {
case <-time.After(1 * time.Second):
fmt.Println("overslept")
case <-ctx.Done():
fmt.Println(ctx.Err()) // prints "context deadline exceeded"
}
// Output:
// context deadline exceeded
}
Go HttpClient 的另一種超時機制
基于 Context 可以設定任意代碼段執行的超時機制，就可以設計一種脫離作業系統能力的請求超時能力，
超時機制簡介
看一下 Go 的 HttpClient 超時配置說明：
client := http.Client{
Timeout: 10 * time.Second,
}
// 來自 src/net/http/client.go
type Client struct {
// ... 省略其他欄位
// Timeout specifies a time limit for requests made by this
// Client. The timeout includes connection time, any
// redirects, and reading the response body. The timer remains
// running after Get, Head, Post, or Do return and will
// interrupt reading of the Response.Body.
//
// A Timeout of zero means no timeout.
//
// The Client cancels requests to the underlying Transport
// as if the Request's Context ended.
//
// For compatibility, the Client will also use the deprecated
// CancelRequest method on Transport if found. New
// RoundTripper implementations should use the Request's Context
// for cancellation instead of implementing CancelRequest.
Timeout time.Duration
}
翻譯一下注釋：Timeout 包括了連接、redirect、讀取資料的時間，定時器會在 Timeout 時間后打斷資料的讀取，設為0則沒有超時限制，
也就是說這個超時是一個請求的總體超時時間，而不必再分別去設定連接超時、讀取超時等等，
這對于使用者來說可能是一個更好的選擇，大部分場景，使用者不必關心到底是哪部分導致的超時，而只是想這個 HTTP 請求整體什么時候能回傳，
超時機制底層原理
以一個最簡單的例子來闡述超時機制的底層原理，
這里我起了一個本地服務，用 Go HttpClient 去請求，超時時間設定為 10 分鐘，建議使 Debug 時設定長一點，否則可能超時導致無法走完全流程，
client := http.Client{
Timeout: 10 * time.Minute,
}
resp, err := client.Get("http://127.0.0.1:81/hello")
1. 根據 timeout 計算出超時的時間點
// 來自 src/net/http/client.go
deadline = c.deadline()
2. 設定請求的 cancel
// 來自 src/net/http/client.go
stopTimer, didTimeout := setRequestCancel(req, rt, deadline)
這里回傳的 stopTimer 就是可以手動 cancel 的方法，didTimeout 是判斷是否超時的方法，這兩個可以理解為回呼方法，呼叫 stopTimer() 可以手動 cancel，呼叫 didTimeout() 可以回傳是否超時，
設定的主要代碼其實就是將請求的 Context 替換為 cancelCtx，后續所有的操作都將攜帶這個 cancelCtx：
// 來自 src/net/http/client.go
var cancelCtx func()
if oldCtx := req.Context(); timeBeforeContextDeadline(deadline, oldCtx) {
req.ctx, cancelCtx = context.WithDeadline(oldCtx, deadline)
}
同時，再起一個定時器，當超時時間到了之后，將 timedOut 設定為 true，再呼叫 doCancel()，doCancel() 是呼叫真正 RoundTripper （代表一個 HTTP 請求事務）的 CancelRequest，也就是取消請求，這個跟實作有關，
// 來自 src/net/http/client.go
timer := time.NewTimer(time.Until(deadline))
var timedOut atomicBool
go func() {
select {
case <-initialReqCancel:
doCancel()
timer.Stop()
case <-timer.C:
timedOut.setTrue()
doCancel()
case <-stopTimerCh:
timer.Stop()
}
}()
Go 默認 RoundTripper CancelRequest 實作是關閉這個連接
// 位于 src/net/http/transport.go
// CancelRequest cancels an in-flight request by closing its connection.
// CancelRequest should only be called after RoundTrip has returned.
func (t *Transport) CancelRequest(req *Request) {
t.cancelRequest(cancelKey{req}, errRequestCanceled)
}
3. 獲取連接
// 位于 src/net/http/transport.go
for {
select {
case <-ctx.Done():
req.closeBody()
return nil, ctx.Err()
default:
}
// ...
pconn, err := t.getConn(treq, cm)
// ...
}
代碼的開頭監聽 ctx.Done，如果超時則直接回傳，使用 for 回圈主要是為了請求的重試，
后續的 getConn 是阻塞的，代碼比較長，挑重點說，先看看有沒有空閑連接，如果有則直接回傳
// 位于 src/net/http/transport.go
// Queue for idle connection.
if delivered := t.queueForIdleConn(w); delivered {
// ...
return pc, nil
}
如果沒有空閑連接，起個協程去異步建立，建立成功再通知主協程
// 位于 src/net/http/transport.go
// Queue for permission to dial.
t.queueForDial(w)
再接著是一個 select 等待連接建立成功、超時或者主動取消，這就實作了在連接程序中的超時
// 位于 src/net/http/transport.go
// Wait for completion or cancellation.
select {
case <-w.ready:
// ...
return w.pc, w.err
case <-req.Cancel:
return nil, errRequestCanceledConn
case <-req.Context().Done():
return nil, req.Context().Err()
case err := <-cancelc:
if err == errRequestCanceled {
err = errRequestCanceledConn
}
return nil, err
}
4. 讀寫資料
在上一條連接建立的時候，每個鏈接還偷偷起了兩個協程，一個負責往連接中寫入資料，另一個負責讀資料，他們都監聽了相應的 channel，
// 位于 src/net/http/transport.go
go pconn.readLoop()
go pconn.writeLoop()
其中 wirteLoop 監聽來自主協程的資料，并往連接中寫入
// 位于 src/net/http/transport.go
func (pc *persistConn) writeLoop() {
defer close(pc.writeLoopDone)
for {
select {
case wr := <-pc.writech:
startBytesWritten := pc.nwrite
err := wr.req.Request.write(pc.bw, pc.isProxy, wr.req.extra, pc.waitForContinue(wr.continueCh))
// ...
if err != nil {
pc.close(err)
return
}
case <-pc.closech:
return
}
}
}
同理，readLoop 讀取回應資料，并寫回主協程，讀與寫的程序中如果超時了，連接將被關閉，報錯退出，
超時機制小結
Go 的這種請求超時機制，可隨時終止請求，可設定整個請求的超時時間，其實作主要依賴協程、channel、select 機制的配合，總結出套路是：
- 主協程生成 cancelCtx，傳遞給子協程，主協程與子協程之間用 channel 通信
- 主協程 select channel 和 cancelCtx.Done，子協程完成或取消則 return
- 回圈任務：子協程起一個回圈處理，每次回圈開始都 select cancelCtx.Done，如果完成或取消則退出
- 阻塞任務：子協程 select 阻塞任務與 cancelCtx.Done，阻塞任務處理完或取消則退出
以回圈任務為例
Java 能實作這種超時機制嗎
直接說結論：暫時不行，
首先 Java 的執行緒太重，像 Go 這樣一次請求開了這么多協程，換成執行緒性能會大打折扣，
其次 Go 的 channel 雖然和 Java 的阻塞佇列類似，但 Go 的 select 是多路復用機制，Java 暫時無法實作，即無法監聽多個佇列是否有資料到達，所以綜合來看 Java 暫時無法實作類似機制，
總結
本文介紹了 Go 另類且有趣的 HTTP 超時機制，并且分析了底層實作原理，歸納出了這種機制的套路，如果我們寫 Go 代碼，也可以如此模仿，讓代碼更 Go，這期是我寫的 Go 底層原理第一期，求個 贊、在看、分享，我們下期再見，
- 搜索關注微信公眾號"捉蟲大師"，后端技術分享，架構設計、性能優化、原始碼閱讀、問題排查、踩坑實踐，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/534061.html
標籤：Go