之前用go寫的agent , 在持續執行乙個多月後，發現agent本身的cpu 使用率會一直爬高，也就是存在cpu洩漏的問題。
開始初步鎖定範圍是我們的乙個ping 的採集出了問題， 這個ping 我們是修改了fastping的庫來做ping的傳送，但是自查了一遍修改的**，沒發現問題。於是用pprof 抓取cpu 使用率， 發現有大量的runtime.futex 這種syscall 和runtime的shiftdowntimer。如下圖：
這裡推測應該是某處timer 的使用有問題，於是再次翻看修改的fastping庫，才發現在每次會建立的goroutine 當中會建立乙個newticker 來處理timeout ，但是這個newticker 在timeout後，又沒有stop. 所以每次採集的時候都會建立新的newticker，導致futex 越來越多，導致cpu 洩漏。
類似於以下**， 在不斷的開啟goroutine，但是沒有在for {} 結束以後，呼叫timeout.stop()
go recv()
func recv() }}
一、在這種一次性處理timeout 的情況下，是否用time.after或者其它方式更好？
二、不同的timer函式在不同的場景下是否有比較好的使用方式呢？
當然golang 本身的timer可能不滿足特定的場景，要另外構建自己的timer，那是另外一回事啦。
Golang timer可能造成的記憶體洩漏
前兩天，跟一位學長交流golang 然後，他突然問我 你知道timer可能造成記憶體洩漏嘛？當時，甚是一臉懵逼，畢竟之前寫的agent測了好久，都沒發現這個問題啊。今天，就索性了解了下。這裡先說下結論，timer的誤用可能造成某些等待timer的goroutine無法正常退出，導致資源無法釋放 ps...
C OPC的應用 一
很久之前的文章了,現在重新整理下,再發布出來,以後總結使用 專案的設計思路 由組態軟體來進行裝置的控制以及資料的讀取,組態軟體作為opc伺服器提供資料,c 開發自己的程式來作為客戶端來訪問opc伺服器,將資料資訊顯示出來,c 修改opc伺服器中的資料,opc伺服器降控制指令通過組態軟體傳送出去.雖然...
函式的應用一
第 一 定義函式時，首先要確定函式名，函式引數的個數 不確定引數個數的函式 1 1 def my add1 num 可以傳入任意多個引數，但是要注意引數的型別 2 2 result 0 3 3 print type num 4 4 try 為了函式健壯性，捕捉了函式的typeerror異常 5 5 ...