rocketmq發生訊息堆積時，我們可以通過jstack打印出執行緒的堆疊資訊(可連續列印多次觀察變化)。重點搜尋 ConsumeMessageThread_ 開頭的執行緒狀態，例如下圖所示：

如果發現大量的執行緒總是處於runnable狀態，且堆疊資訊中包含類似HttpClientUtil.doGet的資訊，且有可能是因為http請求處理慢，導致大量執行緒被佔用，消費能力不足導致訊息堆積。解決思路，優優http請求，如設定較短的過期時間等。

如果發現大量的消費執行緒處於WAITING(parking)狀態，說明消費執行緒在等待待消費的訊息。如果仍然存在訊息堆積，則極有可能是拉取能力不足，重點應該加強rocketmq拉取訊息的能力。

還有一種假堆積，就是某條訊息消費時，因為某種原因，一直卡住了（既不是消費成功也不是消費失敗，而是類似於死迴圈無法返回消費狀態）。這時候會導致無法更新broker端的消費offset（但後面的訊息還是可以正常拉取消費的），這樣子就導致了消費堆壓報警(判斷訊息堆積是 broker offset - consumer offset(consumer上報broker的))。所以說消費訊息的邏輯一定要簡單，儘量不要丟擲異常或有堵塞發生。