GO中的defer會在當前函數(shù)返回前執(zhí)行傳入的函數(shù)，常用于關閉文件描述符，關閉鏈接及解鎖等操作。
十多年的保山網站建設經驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。營銷型網站建設的優(yōu)勢是能夠根據用戶設備顯示端的尺寸不同，自動調整保山建站的顯示方式，使網站能夠適用不同顯示終端，在瀏覽器中調整網站的寬度，無論在任何一種瀏覽器上瀏覽網站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)從事“保山網站設計”,“保山網站推廣”以來，每個客戶項目都認真落實執(zhí)行。
Go語言中使用defer時會遇到兩個常見問題：
接下來我們來詳細處理這兩個問題。
官方有段對defer的解釋：
這里我們先來一道經典的面試題
你覺得這個會打印什么？
輸出結果：
這里是遵循先入后出的原則，同時保留當前變量的值。
把這道題簡化一下：
輸出結果
上述代碼輸出似乎不符合預期，這個現(xiàn)象出現(xiàn)的原因是什么呢？經過分析，我們發(fā)現(xiàn)調用defer關鍵字會立即拷貝函數(shù)中引用的外部參數(shù)，所以fmt.Println(i)的這個i是在調用defer的時候就已經賦值了，所以會直接打印1。
想要解決這個問題也很簡單，只需要向defer關鍵字傳入匿名函數(shù)
這里把一些垃圾回收使用的字段忽略了。
中間代碼生成階段cmd/compile/internal/gc/ssa.go會處理程序中的defer，該函數(shù)會根據條件不同，使用三種機制來處理該關鍵字
開放編碼、堆分配和棧分配是defer關鍵字的三種方法，而Go1.14加入的開放編碼，使得關鍵字開銷可以忽略不計。
call方法會為所有函數(shù)和方法調用生成中間代碼，工作內容：
defer關鍵字在運行時會調用deferproc，這個函數(shù)實現(xiàn)在src/runtime/panic.go里，接受兩個參數(shù)：參數(shù)的大小和閉包所在的地址。
編譯器不僅將defer關鍵字轉成deferproc函數(shù)，還會通過以下三種方式為所有調用defer的函數(shù)末尾插入deferreturn的函數(shù)調用
1、在cmd/compile/internal/gc/walk.go的walkstmt函數(shù)中，在遇到ODEFFER節(jié)點時會執(zhí)行Curfn.Func.SetHasDefer(true)，設置當前函數(shù)的hasdefer屬性
2、在ssa.go的buildssa會執(zhí)行s.hasdefer = fn.Func.HasDefer()更新hasdefer
3、在exit中會根據hasdefer在函數(shù)返回前插入deferreturn的函喊羨搭數(shù)調用
runtime.deferproc為defer創(chuàng)建了一個runtime._defer結構體、設置它的函數(shù)指針fn、程序計數(shù)器pc和棧指針sp并將相關參數(shù)拷貝到相鄰的內存空間中
最后調用的return0是唯一一個不會觸發(fā)延遲調用的函數(shù)，可以避免deferreturn的遞歸調用。
newdefer的分配方式是從pool緩存池中獲?。?/p>
這三種方式取到的結構體_defer，都會被添加到鏈表的隊頭，這也是為什么defer按照后進先出的順序執(zhí)行。
deferreturn就是從鏈表的隊頭取出并調用jmpdefer傳入需要執(zhí)行的函數(shù)和參數(shù)。
該函數(shù)只有在所有延遲函數(shù)都執(zhí)行后才會返回。
如果我們能夠將部分結構體分配到棧上就可以節(jié)約內存分配帶來的額外開銷。
在call函數(shù)中有在棧上分配
在運行期間deferprocStack只需要設置一些未在編譯期間初始化的字段，就可以將棧上的_defer追加到函數(shù)的鏈表上。
除了分配的位置和堆的不同，其他的大致相同。
Go語言在1.14中通過開放編碼實現(xiàn)defer關鍵字，使用代碼內聯(lián)優(yōu)化defer關鍵的額外開銷并引入函數(shù)數(shù)據派空funcdata管理panic的調用，該優(yōu)化可以將 defer 的調用開銷從 1.13 版本的 ~35ns 降低至 ~6ns 左右。
然而開放編碼作為一種優(yōu)化 defer 關鍵字的方法，它不是在所有的場景下都會開啟的，開放編碼只會在滿足以下的條件時啟用：
如果函數(shù)中defer關鍵字的數(shù)量多于8個或者defer處于循環(huán)中，那么就會禁用鄭拿開放編碼優(yōu)化。
可以看到這里，判斷編譯參數(shù)不用-N，返回語句的數(shù)量和defer數(shù)量的乘積小于15，會啟用開放編碼優(yōu)化。
延遲比特deferBitsTemp和延遲記錄是使用開放編碼實現(xiàn)defer的兩個最重要的結構，一旦使用開放編碼，buildssa會在棧上初始化大小為8個比特的deferBits
延遲比特中的每一個比特位都表示該位對應的defer關鍵字是否需要被執(zhí)行。延遲比特的作用就是標記哪些defer關鍵字在函數(shù)中被執(zhí)行，這樣就能在函數(shù)返回時根據對應的deferBits確定要執(zhí)行的函數(shù)。
而deferBits的大小為8比特，所以該優(yōu)化的條件就是defer的數(shù)量小于8.
而執(zhí)行延遲調用的時候仍在deferreturn
這里做了特殊的優(yōu)化，在runOpenDeferFrame執(zhí)行開放編碼延遲函數(shù)
1、從結構體_defer讀取deferBits，執(zhí)行函數(shù)等信息
2、在循環(huán)中依次讀取執(zhí)行函數(shù)的地址和參數(shù)信息，并通過deferBits判斷是否要執(zhí)行
3、調用reflectcallSave執(zhí)行函數(shù)
1、新加入的defer放入隊頭，執(zhí)行defer時是從隊頭取函數(shù)調用，所以是后進先出
2、通過判斷defer關鍵字、return數(shù)量來判斷是否開啟開放編碼優(yōu)化
3、調用deferproc函數(shù)創(chuàng)建新的延遲調用函數(shù)時，會立即拷貝函數(shù)的參數(shù)，函數(shù)的參數(shù)不會等到真正執(zhí)行時計算
在以下這段代碼中，我們操作一個文件，無論成功與否都需要關閉文件句柄。這里在三處不同的位置都調用了file.Close()方法，代碼顯得非常冗余。
我們利用延遲調用來優(yōu)化代碼。定義后的defer代碼，會在return之前返回，讓代碼顯得更加緊湊，且可讀性變強，對上面的代碼改造如下：
我們通過這個示例來看一下延巖液遲調用與正常代碼之間的執(zhí)行順序
先簡單分析一下代碼邏輯：
從輸出中，我們可以觀察到如下現(xiàn)象：
從這個實例中，我們很明派伍顯觀察到，defer語句是在return之前執(zhí)行
如果一個函數(shù)內定義了多個defer，則調用順序為LIFO（后進先出）方式執(zhí)行。
仍然是相同的例子，但是在TestDefer中我們定義了三個defer輸出，根據LIFO原則，輸出的順序是3rd-2nd-1st，根據最后的結果，也是逆向向上執(zhí)行defer輸出。
就在整理這篇筆記的時候，發(fā)現(xiàn)了自己的認知誤區(qū)，主要是本節(jié)實例三中發(fā)現(xiàn)的，先來看一下英文的描塵棗或述：
對于上面的這段話的理解：
下面是代碼執(zhí)行輸出，我們來一起分析一下：
雖然在a()函數(shù)內，顯示的返回了10，但是main函數(shù)中得到的結果是defer函數(shù)自增后的結果，我們來分析一下代碼：
在這篇文章的上一版，我曾經嘗試用指針取解釋defer修改返回值的類型，但是感覺不夠透徹，也讓閱讀者非常困惑，索性參考了一下go官方blog中的一篇文章，在此基礎上進行了擴展。如需要閱讀原文，可以參考下面的文章。
切換到新語言始終是一大步，尤其是當您的團隊成員只有一個時有該跡寬語言的先前經驗?，F(xiàn)在，Stream 的主要編程語言從 Python 切換到了 Go。這篇文章將解釋stream決定放棄 Python 并轉向 Go 的一些原因。
Go 非?？?。性能類似于 Java 或 C++。對于用例，Go 通常比 Python 快 40 倍。
對于許多應用程序來說，編程語言只是應用程序和數(shù)據庫之間的粘合劑。語言本身的性能通常并不重要。然而，Stream 是一個API 提供商，為 700 家公司和超過 5 億最終用戶提供提要和聊天平臺。多年來，我們一直在優(yōu)化 Cassandra、PostgreSQL、Redis 等，但最終，您會達到所使用語言的極限。Python 是一門很棒的語言，但對于序列化/反序列化、排名和聚合等用例，它的性能相當緩慢。我們經常遇到性能問題，Cassandra 需要 1 毫秒來檢索數(shù)據，而 Python 會花費接下來的 10 毫秒將其轉換為對象。
看看我如何開始 Go 教程中的一小段 Go 代碼。（這是一個很棒的教程，也是學習 Go 的一個芹鍵很好的起點。）
如果您是 Go 新手，那么在閱讀那個小代碼片段時不會有太多讓您感到驚訝的事情。它展示了多個賦值、數(shù)據結構、指針、格式和一個內置的 HTTP 庫。當我第一次開始編程時，我一直喜歡使用 Python 更高級的功能。Python 允許您在編寫代碼時獲得相當?shù)膭?chuàng)意。例如，您可以：
這些功能玩起來很有趣，但是，正如大多數(shù)程序員會同意的那樣，在閱讀別人的作品時，它們通常會使代碼更難理解。Go 迫使你堅持基礎。這使得閱讀任何人的代碼并立即了解發(fā)生了什么變得非常容易。 注意：當然，它實際上有多“容易”取決于您的用例。如果你想創(chuàng)建一個基本的 CRUD API，我仍然推薦 Django + DRF或 Rails。
作為一門語言，Go 試圖讓事情變得簡單。它沒有引入許多新概念。重點是創(chuàng)建一種非?？焖偾乙子谑褂玫暮唵握Z言。它唯一具有創(chuàng)新性的領域是 goroutine 和通道。（100% 正確CSP的概念始于 1977 年，所以這項創(chuàng)新更多是對舊思想的一種新方法。）Goroutines 是 Go 的輕量級線程方法，通道是 goroutines 之間通信的首選方式。Goroutines 的創(chuàng)建非常便宜，并且只需要幾 KB 的額外內存。因為 Goroutine 非常輕量，所以有可能同時運行數(shù)百甚至數(shù)千個。您可以使用通道在 goroutine 之間進行通信。Go 運行時處理所有復雜性。goroutines 和基于通道的并發(fā)方法使得使用所有可用的 CPU 內核和處理并發(fā) IO 變得非常容易——所有這些都不會使開發(fā)復雜化。與 Python/Java 相比，在 goroutine 上運行函數(shù)需要最少的樣板代碼。您只需在函數(shù)調用前加上關鍵字“go”：
Go 的并發(fā)方法很容易使用。與 Node 相比，這是一種有趣的方法，開發(fā)人員必須密切關注異步代碼的處理方式。Go 中并發(fā)的另一個重要方面是競爭檢測器。這樣可以很容易地確定異步代碼中是否存在任何競爭條件。
我們目前用 Go 編寫的嫌州巧最大的微服務編譯需要 4 秒。與以編譯速度慢而聞名的 Java 和 C++ 等語言相比，Go 的快速編譯時間是一項重大的生產力勝利。我喜歡在程序編譯的時候摸魚，但在我還記得代碼應該做什么的同時完成事情會更好。
首先，讓我們從顯而易見的開始：與 C++ 和 Java 等舊語言相比，Go 開發(fā)人員的數(shù)量并不多。根據StackOverflow的數(shù)據， 38% 的開發(fā)人員知道 Java， 19.3% 的人知道 C++，只有 4.6% 的人知道 Go。GitHub 數(shù)據顯示了類似的趨勢：Go 比 Erlang、Scala 和 Elixir 等語言使用更廣泛，但不如 Java 和 C++ 流行。幸運的是，Go 是一種非常簡單易學的語言。它提供了您需要的基本功能，僅此而已。它引入的新概念是“延遲”聲明和內置的并發(fā)管理與“goroutines”和通道。（對于純粹主義者來說：Go 并不是第一種實現(xiàn)這些概念的語言，只是第一種使它們流行起來的語言。）任何加入團隊的 Python、Elixir、C++、Scala 或 Java 開發(fā)人員都可以在一個月內在 Go 上發(fā)揮作用，因為它的簡單性。與許多其他語言相比，我們發(fā)現(xiàn)組建 Go 開發(fā)人員團隊更容易。如果您在博爾德和阿姆斯特丹等競爭激烈的生態(tài)系統(tǒng)中招聘人員，這是一項重要的優(yōu)勢。
對于我們這樣規(guī)模的團隊（約 20 人）來說，生態(tài)系統(tǒng)很重要。如果您必須重新發(fā)明每一個小功能，您根本無法為您的客戶創(chuàng)造價值。Go 對我們使用的工具有很好的支持。實體庫已經可用于 Redis、RabbitMQ、PostgreSQL、模板解析、任務調度、表達式解析和 RocksDB。與 Rust 或 Elixir 等其他較新的語言相比，Go 的生態(tài)系統(tǒng)是一個重大勝利。它當然不如 Java、Python 或 Node 之類的語言好，但它很可靠，而且對于許多基本需求，你會發(fā)現(xiàn)已經有高質量的包可用。
Gofmt 是一個很棒的命令行實用程序，內置在 Go 編譯器中，用于格式化代碼。就功能而言，它與 Python 的 autopep8 非常相似。我們大多數(shù)人并不真正喜歡爭論制表符與空格。格式的一致性很重要，但實際的格式標準并不那么重要。Gofmt 通過使用一種正式的方式來格式化您的代碼來避免所有這些討論。
Go 對協(xié)議緩沖區(qū)和 gRPC 具有一流的支持。這兩個工具非常適合構建需要通過 RPC 通信的微服務。您只需要編寫一個清單，在其中定義可以進行的 RPC 調用以及它們采用的參數(shù)。然后從這個清單中自動生成服務器和客戶端代碼。生成的代碼既快速又具有非常小的網絡占用空間并且易于使用。從同一個清單中，您甚至可以為許多不同的語言生成客戶端代碼，例如 C++、Java、Python 和 Ruby。因此，內部流量不再有模棱兩可的 REST 端點，您每次都必須編寫幾乎相同的客戶端和服務器代碼。.
Go 沒有像 Rails 用于 Ruby、Django 用于 Python 或 Laravel 用于 PHP 那樣的單一主導框架。這是 Go 社區(qū)內激烈爭論的話題，因為許多人主張你不應該一開始就使用框架。我完全同意這對于某些用例是正確的。但是，如果有人想構建一個簡單的 CRUD API，他們將更容易使用 Django/DJRF、Rails Laravel 或Phoenix。對于 Stream 的用例，我們更喜歡不使用框架。然而，對于許多希望提供簡單 CRUD API 的新項目來說，缺乏主導框架將是一個嚴重的劣勢。
Go 通過簡單地從函數(shù)返回錯誤并期望調用代碼來處理錯誤（或將其返回到調用堆棧）來處理錯誤。雖然這種方法有效，但很容易失去問題的范圍，以確保您可以向用戶提供有意義的錯誤。錯誤包通過允許您向錯誤添加上下文和堆棧跟蹤來解決此問題。另一個問題是很容易忘記處理錯誤。像 errcheck 和 megacheck 這樣的靜態(tài)分析工具可以方便地避免犯這些錯誤。雖然這些變通辦法效果很好，但感覺不太對勁。您希望該語言支持正確的錯誤處理。
Go 的包管理絕不是完美的。默認情況下，它無法指定特定版本的依賴項，也無法創(chuàng)建可重現(xiàn)的構建。Python、Node 和 Ruby 都有更好的包管理系統(tǒng)。但是，使用正確的工具，Go 的包管理工作得很好。您可以使用Dep來管理您的依賴項，以允許指定和固定版本。除此之外，我們還貢獻了一個名為的開源工具VirtualGo，它可以更輕松地處理用 Go 編寫的多個項目。
我們進行的一個有趣的實驗是在 Python 中使用我們的排名提要功能并在 Go 中重寫它?？纯催@個排名方法的例子：
Python 和 Go 代碼都需要執(zhí)行以下操作來支持這種排名方法：
開發(fā) Python 版本的排名代碼大約花了 3 天時間。這包括編寫代碼、單元測試和文檔。接下來，我們花了大約 2 周的時間優(yōu)化代碼。其中一項優(yōu)化是將分數(shù)表達式 (simple_gauss(time)*popularity) 轉換為抽象語法樹. 我們還實現(xiàn)了緩存邏輯，可以在未來的特定時間預先計算分數(shù)。相比之下，開發(fā)此代碼的 Go 版本大約需要 4 天時間。性能不需要任何進一步的優(yōu)化。因此，雖然 Python 的最初開發(fā)速度更快，但基于 Go 的版本最終需要我們團隊的工作量大大減少。另外一個好處是，Go 代碼的執(zhí)行速度比我們高度優(yōu)化的 Python 代碼快大約 40 倍?，F(xiàn)在，這只是我們通過切換到 Go 體驗到的性能提升的一個示例。
與 Python 相比，我們系統(tǒng)的其他一些組件在 Go 中構建所需的時間要多得多。作為一個總體趨勢，我們看到 開發(fā) Go 代碼需要更多的努力。但是，我們花更少的時間 優(yōu)化 代碼以提高性能。
我們評估的另一種語言是Elixir.。Elixir 建立在 Erlang 虛擬機之上。這是一種迷人的語言，我們之所以考慮它，是因為我們的一名團隊成員在 Erlang 方面擁有豐富的經驗。對于我們的用例，我們注意到 Go 的原始性能要好得多。Go 和 Elixir 都可以很好地服務數(shù)千個并發(fā)請求。但是，如果您查看單個請求的性能，Go 對于我們的用例來說要快得多。我們選擇 Go 而不是 Elixir 的另一個原因是生態(tài)系統(tǒng)。對于我們需要的組件，Go 有更成熟的庫，而在許多情況下，Elixir 庫還沒有準備好用于生產環(huán)境。培訓/尋找開發(fā)人員使用 Elixir 也更加困難。這些原因使天平向 Go 傾斜。Elixir 的 Phoenix 框架看起來很棒，絕對值得一看。
Go 是一種非常高性能的語言，對并發(fā)有很好的支持。它幾乎與 C++ 和 Java 等語言一樣快。雖然與 Python 或 Ruby 相比，使用 Go 構建東西確實需要更多時間，但您將節(jié)省大量用于優(yōu)化代碼的時間。我們在Stream有一個小型開發(fā)團隊，為超過 5 億最終用戶提供動力和聊天。Go 結合了 強大的生態(tài)系統(tǒng) 、新開發(fā)人員的 輕松入門、快速的性能 、對并發(fā)的 可靠支持和高效的編程環(huán)境 ，使其成為一個不錯的選擇。Stream 仍然在我們的儀表板、站點和機器學習中利用 Python 來提供個性化的訂閱源. 我們不會很快與 Python 說再見，但今后所有性能密集型代碼都將使用 Go 編寫。我們新的聊天 API也完全用 Go 編寫。
基本設計思路：
類型轉換、類型斷言、動態(tài)派發(fā)。iface，eface。
反射對象具有的方法：
編譯優(yōu)化：
內部實現(xiàn)：
實現(xiàn) Context 接口有以下幾個類型（空實現(xiàn)就忽略了）：
互斥鎖的控制邏輯：
設計思路：
（以上為寫被讀阻塞，下面是讀被寫阻塞）
總結，讀寫鎖的設計還是非常巧妙的：
設計思路：
WaitGroup 有三個暴露的函數(shù):
部件：
設計思路：
結構：
Once 只暴露了一個方法：
實現(xiàn)：
三個關鍵點：
細節(jié)：
讓多協(xié)程任務的開始執(zhí)行時間可控（按順序或歸一）。（Context 是控制結束時間）
設計思路： 通過一個鎖和內置的 notifyList 隊列實現(xiàn)，Wait() 會生成票據，并將等待協(xié)程信息加入鏈表中，等待控制協(xié)程中發(fā)送信號通知一個（Signal()）或所有（Boardcast()）等待者（內部實現(xiàn)是通過票據通知的）來控制協(xié)程解除阻塞。
暴露四個函數(shù)：
實現(xiàn)細節(jié)：
部件：
包： golang.org/x/sync/errgroup
作用：開啟 func() error 函數(shù)簽名的協(xié)程，在同 Group 下協(xié)程并發(fā)執(zhí)行過程并收集首次 err 錯誤。通過 Context 的傳入，還可以控制在首次 err 出現(xiàn)時就終止組內各協(xié)程。
設計思路：
結構：
暴露的方法：
實現(xiàn)細節(jié)：
注意問題：
包： "golang.org/x/sync/semaphore"
作用：排隊借資源（如肢州錢，有借有還）的一種場景。此包相當于對底層信號量的一種暴露。
設計思路：有一定數(shù)量的資源 Weight，每一個 waiter 攜帶一個 channel 和饑激要借的數(shù)量 n。通過隊列排隊執(zhí)行借貸。
結構：
暴露方法：
細節(jié)：
部件：
細節(jié)：
包： "golang.org/x/sync/singleflight"
作用：防擊穿。瞬時的相同請求只調用一次，response 被所有相同請求共享。
設計思路：按請求的 key 分組（一爛饑襪個 *call 是一個組，用 map 映射存儲組），每個組只進行一次訪問，組內每個協(xié)程會獲得對應結果的一個拷貝。
結構：
邏輯：
細節(jié)：
部件：
如有錯誤，請批評指正。
