今天寫了一段垃圾代碼，然后上服務器上運行，cpu瞬間飆到了100%，現記錄一下問題排除過程~ 1. 問題代碼 2. top 3. 查找問題 3.1 top -Hp 18571, 找出最耗cpu的線程，結果發現18584是就耗了99.9 ...

主要環境與用到的（關鍵）組件： 首先是服務報錯： 很多使用過dubbo的同學對這個報錯信息應該都不陌生，一般情況下，如果沒有配置好生產端、消費端或者注冊中心，啟動的時候就會報這個錯。但這里的情況是，消費端和生產端都已經正常運行了一段時間了，大概10天左右，突然報 ...

1. 問題描述：早上剛來上班，業務部門同事反應管理后台無法登錄 2. 問題排查定位 2.1 服務器排查 a. 接口是否可以調通：首先自己登陸后台，發現時好時壞，偶爾接口返回【系統忙】。我們系統接口異常調不通會返回系統忙 b. 服務是否死掉或者假死：連接服務器->查看Java ...

今天在調試定時器時，定時器3出現了自動停止工作的問題，中斷設置是每過一秒，進一次中斷，相應標志位+1，然后每次都是在標志位=4時停止工作，但是有時候又能正常工作，暫時未解決。 在調試時，發現一個有趣的現象，本次項目我同時配置了定時器4，初始化后是DISABLE未使能狀態，但是開始運行，定時器 ...

定時器，它都會立即進入一次定時器更新中斷服務程序。 以STM32F051芯片為例，做了幾種不同順序的 ...

背景 將log4j.xml的日志級別從error調整為info后,進行壓測發現CPU占用很高達到了90%多(之前也就是50%,60%的樣子). 問題排查 排查思路: 看進程中的線程到底執行的是什么,導致CPU占用較高. 1. 使用top命令查看到底是哪個應用 ...

現象：通過nginx訪問，偶現502 排查步驟： 1、查看日志，無異常日志打印 2、抓包分析，發現發送http請求后，被源站直接發fin。 3、注釋代碼關鍵邏輯，測試。定位到是access.lua階段處理的問題。但因為沒有日志，代碼段太多，只能逐步排查 ...

前言 之前或多或少分享過一些內存模型、對象創建之類的內容，其實大部分人看完都是懵懵懂懂，也不知道這些的實際意義。 直到有一天你會碰到線上奇奇怪怪的問題，如： 線程執行一個任務遲遲沒有返回，應用假死。 接口響應緩慢，甚至請求超時。 CPU 高負載運行。 這類問題並不 ...