原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 簡介 在上篇文章中，介紹了使用tcmalloc或jemalloc定位native內存泄露的方法，但使用這個方法相當于更換了原生內存分配器，以至于使用時會有一些顧慮。 經過一些摸索，發現glibc自帶的ptmall 閱讀全文
> 原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 ### 問題現象 7月25號，我們一服務的內存占用較高，約13G，容器總內存16G，占用約85%，觸發了內存報警(閾值85%)，而我們是按容器內存60%(9.6G)的比例配置的JVM堆內存?？戳讼缕渌?，同 閱讀全文
> 原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 ### 簡介 我們組有一個流量較大的Java服務，每次發代碼時，服務都會有一小波接口超時，之前簡單分析過，發現這些超時的case僅發生在服務剛啟動時，少量請求會耗時好幾秒，但之后又馬上恢復正常。 ### 問題 閱讀全文
> 原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 ### 簡介 經常有小哥發出疑問，SQL還能這么寫？我經常笑著回應，SQL確實可以這么寫。其實SQL學起來簡單，用起來也簡單，但它還是能寫出很多變化，這些變化讀懂它不難，但要自己Get到這些變化，可能需要想一 閱讀全文
原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 簡介 在之前的OOM問題復盤之后，本周，又一Java服務出現了內存問題，這次問題不嚴重，只會觸發堆內存占用高報警，沒有觸發OOM，但好在之前的復盤中總結了dump腳本，會在堆占用高時自動執行jstack與jmap 閱讀全文
原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 在之前的OOM問題復盤中，我們添加了jmap腳本來自動dump內存現場，方便排查OOM問題。 但當我反復模擬OOM場景測試時，發現jmap有時可以dump成功，有時會報錯，如下： 經過網上一頓搜索，發現兩種原因可 閱讀全文
原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 上個月，我們一個java服務上線后，偶爾會發生內存OOM(Out Of Memory)問題，但由于OOM導致服務不響應請求，健康檢查多次不通過，最后部署平臺kill了java進程，這導致定位這次OOM問題也變得困 閱讀全文
原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 問題發生 上上周，看到一位老哥找我們組同事聯調接口，不知道是什么問題，兩人坐一起搞了快1個小時，看起來好像有點復雜。 突然，老哥發出一聲臥槽，"我傳參里的+號，到你這怎么變成了空格！"，這個聲音很大，我明顯的聽到 閱讀全文
原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 問題發生 這周正在寫代碼，突然，旁邊小哥問我個問題... 小哥：我這有個接口，自己調用沒有問題，但別人調用就不行，這種問題該如何排查？ 我：抓下包看看呢... 小哥：是這樣使用tcpdump嗎？ 我：是的 待小哥 閱讀全文
原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 簡介 現如今，有兩種常見的軟件資源幾乎成了Java后端程序的標配，即線程池與連接池，但這些池化資源非常的重要，一旦不夠用了，就會導致程序阻塞、性能低下，所以有時我們需要看看它們的使用情況，以判斷這里是否是瓶頸。 閱讀全文
