今天遇到乙個很尷尬的問題，就是eventbus的使用過程中，在post乙個event後，於此同時，在接收event的方法中打斷點監控event的接收。
這個時候我遇到很尷尬的問題，會重複接收到很多次的event事件= =
我當前所用的開發框架是支援將業務，資料更新，檢視更新從activity中抽離，在activity例項化的時候使用反射的方式建立對應的業務controller，然後controller的生命週期將全程與activity的生命週期繫結，整體的想法和fragment一致，其實挺棒的。
但是最近寫相關框架的老大比較忙，其實這個框架還能編的更棒，明明可以在controller上面進一步繫結controller，這樣一來，能達到將行為進一步抽離的目的= =，嘛嘛，事物永遠不可能剛開始就極其完美，這才有不斷改進的空間。
那麼就是因為框架使用習慣了，而且我一直想在controller上面套controller，結果就造成我以為現在的框架已經支援controller之間互相巢狀的錯覺= =。
eventbus並沒有及時unregister對應的subscriber，因為eventbus對訂閱者管理採用的是強引用列表的方式，所以如果你會手動呼叫解綁方法，物件將會一直儲存在記憶體中，進而導致記憶體洩露。在適當的位置手動呼叫解綁方法就能解決這個問題了。我這裡出現這樣的問題的根本原因就是將解綁操作寫到了ondestroy內，因為我之前說過了，ondestroy的呼叫是通過框架自動完成的，但是這裡這種情況，框架並不會自動呼叫對應的方法，所以對於事件event依然會響應，就出現了重複接收多次的結果。
記CXF中的一次Non Heap記憶體洩露
最近遇到乙個webservice記憶體洩露的問題。使用jconsole連線後發現非堆記憶體和loaded classes在每次執行full gc後都會增長。classes增長的非常有規律，每次增加5000個左右。因為cxf中使用了jaxb，懷疑是jaxb被多次例項化造成的。然後使用mat，查詢dup...
記一次Pytorch記憶體洩露的排查與處理
模型訓練過程中記憶體占用不斷增加,訓練到30000輪左右已經占用到200g記憶體.查詢了網上的一些記憶體洩漏排查方法,使用了memory profiler objgraph pympler這三個工具進行排查 參考鏈結如下 pytorch超出記憶體 pytorch記憶體洩漏分析案例 list轉tens...
記一次goto記憶體洩漏
學習c語言時一直被告誡盡量不要使用goto語句，所以對其了解很少。在一次專案使用時由於之前的程式已經使用了goto，按照自己的理解去處理，結果導致記憶體未釋放。例子如下 include int main return 0 error printf aaaaa n printf 11111.n ret...