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 底層原理第一期，求個 贊、在看、分享，我們下期再見。

搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。

有趣的 Go HttpClient 超時機制