建站
咨詢
售后
建站咨詢
新聞中心
GO語言之recover
????運行panic異常一旦被引發(fā)就會導(dǎo)致程序崩潰，這當(dāng)然不是我們愿意看到的，go語言提供樂專用于“攔截”運行時panic的內(nèi)建函數(shù)-recover，它可以是當(dāng)前的程序從運行時panic的狀態(tài)中恢復(fù)并重新獲得流程控制權(quán)。
堅守“ 做人真誠 · 做事靠譜 · 口碑至上 · 高效敬業(yè) ”的價值觀，專業(yè)網(wǎng)站建設(shè)服務(wù)10余年為成都成都電動窗簾小微創(chuàng)業(yè)公司專業(yè)提供成都定制網(wǎng)站營銷網(wǎng)站建設(shè)商城網(wǎng)站建設(shè)手機網(wǎng)站建設(shè)小程序網(wǎng)站建設(shè)網(wǎng)站改版，從內(nèi)容策劃、視覺設(shè)計、底層架構(gòu)、網(wǎng)頁布局、功能開發(fā)迭代于一體的高端網(wǎng)站建設(shè)服務(wù)。
????注意：recover只有在defer調(diào)用的函數(shù)中有效
????如果調(diào)用了內(nèi)置函數(shù)recover，并且定義該defer語句的函數(shù)發(fā)生了panic異常，recover會使用程序從panic中恢復(fù)，并且返回panic value，導(dǎo)致panic異常的函數(shù)不會繼續(xù)執(zhí)行，但能正常返回。在未發(fā)生panic時調(diào)用recover，recover會返回nil。
go語言對象的問題？
Get轉(zhuǎn)到定義是如下代碼，
func (c *Client) Get(url string) (resp *Response, err error) {
req, err := NewRequest("GET", url, nil)
if err != nil {
return nil, err
}
return c.Do(req)
}
看上去已經(jīng)有足夠多的動作了，并不是你說的只是一個接口啊
GO語言（十八）：模糊測試入門（下）-
Reverse為了解決這個問題，如果輸入不是有效的 UTF-8 ，讓我們返回一個錯誤。
a.在您的文本編輯器中，將現(xiàn)有Reverse函數(shù)替換為以下內(nèi)容。
如果輸入字符串包含無效的 UTF-8 字符，此更改將返回錯誤。
b.由于 Reverse 函數(shù)現(xiàn)在返回錯誤，因此修改main函數(shù)以丟棄額外的錯誤值。將現(xiàn)有main功能替換為以下內(nèi)容。
這些調(diào)用Reverse應(yīng)該返回一個 nil 錯誤，因為輸入字符串是有效的 UTF-8。
c.您將需要導(dǎo)入錯誤和 unicode/utf8 包。main.go 中的 import 語句應(yīng)如下所示。
d.修改reverse_test.go文件檢查是否有錯誤，如果返回產(chǎn)生錯誤則跳過測試。
除了返回之外，您還可以調(diào)用t.Skip()以停止執(zhí)行該模糊輸入。
a.使用 go test 運行測試
b.使用go test -fuzz=Fuzz進行模糊測試，幾秒鐘后，停止用ctrl-C模糊測試。
除非您通過-fuzztime標志進行限制，否則模糊測試將一直運行，直到遇到失敗的輸入。如果沒有發(fā)生故障，默認是永遠運行，并且可以使用 中斷該過程ctrl-C。
c. 使用go test -fuzz=Fuzz -fuzztime 30s。如果沒有30 秒發(fā)現(xiàn)失敗，它會在退出模糊測試。
模糊測試通過了！
做得很好！您剛剛學(xué)習(xí)了在 Go 中進行模糊測試。
— main.go —
— reverse_test.go —
golang sync.pool對象復(fù)用 并發(fā)原理 緩存池
在go http每一次go serve(l)都會構(gòu)建Request數(shù)據(jù)結(jié)構(gòu)。在大量數(shù)據(jù)請求或高并發(fā)的場景中，頻繁創(chuàng)建銷毀對象，會導(dǎo)致GC壓力。解決辦法之一就是使用對象復(fù)用技術(shù)。在http協(xié)議層之下，使用對象復(fù)用技術(shù)創(chuàng)建Request數(shù)據(jù)結(jié)構(gòu)。在http協(xié)議層之上，可以使用對象復(fù)用技術(shù)創(chuàng)建(w,*r,ctx)數(shù)據(jù)結(jié)構(gòu)。這樣即可以回快TCP層讀包之后的解析速度，也可也加快請求處理的速度。
先上一個測試：
結(jié)論是這樣的：
貌似使用池化，性能弱爆了？？？這似乎與net/http使用sync.pool池化Request來優(yōu)化性能的選擇相違背。這同時也說明了一個問題，好的東西，如果濫用反而造成了性能成倍的下降。在看過pool原理之后，結(jié)合實例，將給出正確的使用方法，并給出預(yù)期的效果。
sync.Pool是一個 協(xié)程安全 的 臨時對象池 。數(shù)據(jù)結(jié)構(gòu)如下：
local 成員的真實類型是一個 poolLocal 數(shù)組，localSize 是數(shù)組長度。這涉及到Pool實現(xiàn)，pool為每個P分配了一個對象，P數(shù)量設(shè)置為runtime.GOMAXPROCS(0)。在并發(fā)讀寫時，goroutine綁定的P有對象，先用自己的，沒有去偷其它P的。go語言將數(shù)據(jù)分散在了各個真正運行的P中，降低了鎖競爭，提高了并發(fā)能力。
不要習(xí)慣性地誤認為New是一個關(guān)鍵字，這里的New是Pool的一個字段，也是一個閉包名稱。其API：
如果不指定New字段，對象池為空時會返回nil，而不是一個新構(gòu)建的對象。Get()到的對象是隨機的。
原生sync.Pool的問題是，Pool中的對象會被GC清理掉，這使得sync.Pool只適合做簡單地對象池，不適合作連接池。
pool創(chuàng)建時不能指定大小，沒有數(shù)量限制。pool中對象會被GC清掉，只存在于兩次GC之間。實現(xiàn)是pool的init方法注冊了一個poolCleanup()函數(shù)，這個方法在GC之前執(zhí)行，清空pool中的所有緩存對象。
為使多協(xié)程使用同一個POOL。最基本的想法就是每個協(xié)程，加鎖去操作共享的POOL，這顯然是低效的。而進一步改進，類似于ConcurrentHashMap（JDK7）的分Segment，提高其并發(fā)性可以一定程度性緩解。
注意到pool中的對象是無差異性的，加鎖或者分段加鎖都不是較好的做法。go的做法是為每一個綁定協(xié)程的P都分配一個子池。每個子池又分為私有池和共享列表。共享列表是分別存放在各個P之上的共享區(qū)域，而不是各個P共享的一塊內(nèi)存。協(xié)程拿自己P里的子池對象不需要加鎖，拿共享列表中的就需要加鎖了。
Get對象過程：
Put過程：
如何解決Get最壞情況遍歷所有P才獲取得對象呢：
方法1止前sync.pool并沒有這樣的設(shè)置。方法2由于goroutine被分配到哪個P由調(diào)度器調(diào)度不可控，無法確保其平衡。
由于不可控的GC導(dǎo)致生命周期過短，且池大小不可控，因而不適合作連接池。僅適用于增加對象重用機率，減少GC負擔(dān)。2
執(zhí)行結(jié)果:
單線程情況下，遍歷其它無元素的P，長時間加鎖性能低下。啟用協(xié)程改善。
結(jié)果：
測試場景在goroutines遠大于GOMAXPROCS情況下，與非池化性能差異巨大。
測試結(jié)果
可以看到同樣使用*sync.pool，較大池大小的命中率較高，性能遠高于空池。
結(jié)論：pool在一定的使用條件下提高并發(fā)性能，條件1是協(xié)程數(shù)遠大于GOMAXPROCS，條件2是池中對象遠大于GOMAXPROCS。歸結(jié)成一個原因就是使對象在各個P中均勻分布。
池pool和緩存cache的區(qū)別。池的意思是，池內(nèi)對象是可以互換的，不關(guān)心具體值，甚至不需要區(qū)分是新建的還是從池中拿出的。緩存指的是KV映射，緩存里的值互不相同，清除機制更為復(fù)雜。緩存清除算法如LRU、LIRS緩存算法。
池空間回收的幾種方式。一些是GC前回收，一些是基于時鐘或弱引用回收。最終確定在GC時回收Pool內(nèi)對象，即不回避GC。用java的GC解釋弱引用。GC的四種引用：強引用、弱引用、軟引用、虛引用。虛引用即沒有引用，弱引用GC但有空間則保留，軟引用GC即清除。ThreadLocal的值為弱引用的例子。
regexp 包為了保證并發(fā)時使用同一個正則，而維護了一組狀態(tài)機。
fmt包做字串拼接，從sync.pool拿[]byte對象。避免頻繁構(gòu)建再GC效率高很多。
go語言中fmt.Println(s0==nil)什么意思？
對于某些類型的變量，如指針、切片、map、接口、通道、函數(shù)等，如果從未為它賦過值，則它將具有默認值nil。這句代碼的意思就是，如果s0未初始化過，就打印true，否則打印false。
分享文章：go語言怎么返回nil go語言簡明教程
本文網(wǎng)址：http://ef60e0e.cn/article/hicpjh.html
