最近，我們正在對流行的SaaS應用程序進行故障排除。 該應用程序間歇性地減慢了速度。 要從問題中恢復，必須重新啟動應用程序。 在高流量期間，此應用有時會變慢； 有時在交通繁忙時也是如此。 沒有凝聚力模式。

這種應用程序變慢并重新啟動它持續了一段時間。 然后，我們開始解決問題。 我們發現了一些有趣的東西，以為您也可以從我們的發現中受益，因此撰寫了本文。

技術棧

這個流行的SaaS應用程序在Azure云上運行。 下面是它的技術堆棧：

+ Spring框架

+ GlassFish應用服務器

+ Java 8

+ Azure云

故障排除

得知此問題后，我們就在發生減速時從該應用程序捕獲了線程轉儲。 有多種捕獲線程轉儲的選項 ； 我們選擇了“ jstack”工具來捕獲線程轉儲。

注意：發生問題時，正確獲取線程轉儲非常重要。 在問題持續時間窗口之外捕獲的線程轉儲將無用。

現在，我們將捕獲的線程轉儲上傳到fastThread.io –在線線程轉儲分析工具。 該工具立即生成了此精美報告 。 （我們建議您單擊超鏈接以查看生成的報告，以便獲得第一手的經驗）。

該報告立即縮小了問題的根本原因。 fastThread.io工具突出顯示“ http-nio-8080-exec-121”線程正在阻止134個應用程序線程。 下面是傳遞依賴關系圖，顯示了已阻塞的線程：

圖：fastThread.io顯示了已阻塞線程的傳遞依賴關系

從該圖可以看到134個應用程序線程被“ http-nio-8080-exec-121”線程阻塞（第一個從左側開始）。 當我們單擊圖中的“ http-nio-8080-exec-121”超鏈接時，它會打印線程的堆棧跟蹤：

圖：http-nio-8080-exec-121獲得的org.apache.log4j.Logger鎖

我要求您仔細查看堆棧跟蹤中突出顯示的部分。 您可以看到線程獲得org.apache.log4j.Logger鎖，然后繼續前進以將日志記錄寫入Azure云存儲。

現在，讓我們看一下“ http-nio-8080-exec-56”線程（134個被阻塞的線程之一）的堆棧跟蹤：

圖：http-nio-8080-exec-56等待獲得org.apache.log4j.Logger鎖

看一下上面堆棧跟蹤中突出顯示的部分。 它正在等待獲取org.apache.log4j.Logger鎖。 您可以看到'http-nio-8080-exec-56'線程處于BLOCKED狀態，因為'http-nio-8080-exec-114'獲得了org.apache.log4j.Logger鎖并且沒有釋放它。

其余的134個線程也被卡住，等待'org.apache.log4j.Logger'鎖。 因此，每當任何應用程序線程嘗試登錄時，它都會進入此BLOCKED狀態。 因此134個應用程序線程結束進入此BLOCKED狀態。

然后，我們用google搜索org.apache.log4j.Logger BLOCKED線程。 我們偶然發現了Apache Log4j錯誤數據庫中報告的這個有趣的缺陷 。

事實證明，這是Log4J框架中的已知錯誤之一，也是開發新Log4j2框架的主要原因之一。 以下是該缺陷描述的有趣摘錄：

沒有針對此問題的臨時修復程序，這是Log4j 2出現的原因之一。 唯一的解決方法是升級到Log4j 2。

是的，我是說Log4j 2中的代碼有很大不同，并且鎖定的處理方式也有很大不同。 根記錄器或附加器循環上沒有鎖。

由于該錯誤，任何試圖登錄的線程都進入了“阻塞”狀態。 這導致整個應用程序停止運行。 將應用程序從Log4j遷移到Log4j2框架后，問題得到解決。

結論

1. Log4j已于2015年8月達到停產（已停產）。不再受支持。 如果您的應用程序仍在使用Log4J框架，我們強烈建議您升級到Apache Log4j2框架。 這是遷移指南 。 Log4j2不僅僅是Log4j框架的下一版本； 這是一個從頭開始編寫的新框架。 它具有很多性能改進。

2.此外，現在您還可以學習如何對無響應的應用程序進行故障排除。

翻譯自: https://www.javacodegeeks.com/2020/01/log4j-bug-slows-down-your-app.html

總結

以上是生活随笔為你收集整理的Log4j Bug –减慢您的应用程序的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。