一個用Java寫的GUI程式，作用是分析日誌， 它會將一定數量的格式相同的文字日誌檔案讀入記憶體分析處理，然後將結果合併輸出。

檔案數量幾十個，檔案大小几KB， 日誌記錄幾千條左右， 此工具可以流暢處理， 輕鬆滿足需求。

然而， 因為記錄日誌的方案調整，記錄日誌類型範圍從warn、error級別擴大到了連info、debug級別的日誌也要記錄，從而導致了日誌量激增， 固定時間範圍內產生的日誌檔案增加到了幾百個， 單個大小也增加到幾M，日誌記錄一下子達到幾十萬條，然後工具就跑的跟蝸牛一樣慢， 幾十秒才能出結果。

要繼續使用這個工具，自然需要優化，要優化則需要定位效能瓶頸在哪裡。 這個工具不復雜，沒有複雜的計算， 也沒有無謂的執行損耗， 最可能導致問題的地方是檔案內容讀取的I/O開銷，可是以Java的能耐，從幾百個檔案中讀取幾百M內容， 沒有可能需要幾十秒時間。 而且為了提升速度我還使用了多執行緒處理，使用執行緒池為每個日誌檔案的讀取和處理分配一個執行緒，於是我以此處為中心開始分析問題所在，直覺上， 執行緒的使用總是容易和效能問題聯絡在一起。

因為使用

Executors.newCachedThreadPool()

建立我所使用的執行緒池，而使用這個執行緒池太過於潦草， 它沒有大小限制，為每個日誌檔案的處理分配一個執行緒，假如有100個檔案需要處理， 那麼執行緒池就會建立100個執行緒， 而我的機器CPU只有4核心，顯然這100個執行緒無法被同時執行，而且還增加了執行緒之間切換的開銷，所以懷疑這是導致效能問題的原因之一。

從相關網路資料中得知，最佳執行緒數目可通過以下公式確定

最佳執行緒數目 = （（執行緒等待時間+執行緒CPU時間）/執行緒CPU時間 ）* CPU數目

顯然，公式中所有變數除了CPU數目， 其它一概不知，所以我採用了另外一個簡單粗暴的公式

執行緒資料 = 2 * CPU核心數 + 1

這是I/O密集型程式的計算公式。因為這個工具需要頻繁讀取磁碟檔案，所以我將他定位為I/O密集型

ExecutorServiceexecutorService=Executors.newFixedThreadPool(9);

通過使用有數量限制的執行緒池對程式進行改進後，執行速度似乎有所改善， 可是對於讓程式以可以接受的速度執行而言卻是杯水車薪。當然，我本來也對此改進沒有抱多大希望，因為上百個執行緒的切換不可能要花幾十秒。

我知道程式存在問題， 可對於一個沒有問題的程式在正常情況下處理這些日誌檔案需要花多少時間沒有一個明確的概念，所以並沒有充足的信心確定程式出問題的模組所在，只能沒有證據的猜測， 因此不能迅速的定位問題所在。

可能是直覺的將效能與併發和執行緒掛鉤，因此接下來的優化仍舊以這個主題進行。

我決定將日誌檔案的讀取與處理分開，讀取檔案使用一個執行緒， 日誌資料處理使用一個執行緒， 讀取檔案的執行緒將讀取的內容存入一個阻塞佇列，資料處理響執行緒從阻塞佇列中讀取資料進行處理，這是典型的生產消費模式。

費了很大力氣實現這個模式，信心滿滿的以為程式的執行速度會有所改善，然而，出乎意料的程式執行的速度非但沒有改善，而且比以前更加緩慢了，並且伴隨卡死的現象， 我很沮喪， 可不得不承認，效能瓶頸不在併發處理上，朝這個方向優化永遠不能解決問題，高大上的併發技能在這裡毫無用武之地。

我意識必須不斷縮小問題範圍，精確定位到問題程式碼所在，才能啃掉這塊骨頭。

我雖然懷疑效能瓶頸在檔案讀取上，可並沒有明確證據， 必須需要一個明確的資料指標才行。

我在程式的關鍵部位加上除錯程式碼，計算執行各個環節所需要的時間，從資料中明確得知，大部分時間的確被檔案讀取佔用了。

我定位到最接近檔案的程式碼，一個從其它專案中拷貝過來的方法

publicstaticStringreadStringFromFile(Filefile){

try{

if(file.isFile()&&file.exists()){

InputStreamReaderread=newInputStreamReader(newFileInputStream(file),"UTF-8");

BufferedReaderbufferedReader=newBufferedReader(read);

StringlineTxt=bufferedReader.readLine();

Stringresult="";

while(lineTxt!=null){

result+=lineTxt;

lineTxt=bufferedReader.readLine();

}

returnresult;

}

}catch(IOExceptione){

e.printStackTrace();

}

returnnull;

}

這個方法似乎沒什麼毛病， 還使用 BufferedReader 來提升效能，我百思不得其解，並開始推測問題所在。

程式是逐行讀去內容的，問題會不會出現在這裡？

如果一次性讀取整個檔案的內容速度會不會快一點？

正思考間，目光被一行程式碼吸引

result+=lineTxt;

然後靈光一現，一個程式設計概念再我腦海中閃現：String型別是執行緒安全的，狀態不可變， 每次操作都會複製一個自身的副本，因此效能很低，在頻繁拼接字串的情況下， 應該以StringBuffer或者StringBuilder代替String。

幾百個日誌檔案， 幾十萬條日誌記錄，即使一行一條記錄， Java虛擬機器也執行了幾十萬次的字串的拷貝，速度慢是必然的。

確定問題所在，改進就很容易了，我用StringBuilder類替代String進行字串處理

publicstaticStringreadStringFromFile(Filefile){

try{

if(file.isFile()&&file.exists()){

InputStreamReaderread=newInputStreamReader(newFileInputStream(file),"UTF-8");

BufferedReaderbufferedReader=newBufferedReader(read);

StringlineTxt=bufferedReader.readLine();

StringBuilderresult=newStringBuilder();

while(lineTxt!=null){

result.append(lineTxt);

lineTxt=bufferedReader.readLine();

}

returnresult.toString();

}

}catch(IOExceptione){

e.printStackTrace();

}

returnnull;

}

程式執行速度提升驚人，之前幾十秒才能出的結果，現在不到一秒就完成，問題迎刃而解。 至於為什麼不用StringBuffer是因為StringBuffer是StringBuffer的併發安全版本，效能略微不及StringBuider，而這裡不存在併發處理問題，因此自然選著效能更優的StringBuilder。

只改三行程式碼就能解決的問題卻令我折騰了半天， 究其原因在於以下原因

1. 思路先入為主， 總是把效能問題和併發掛上鉤，利用多執行緒處理優化
2. 憑直覺判斷問題形成的原因，沒有確切的依據， 致使優化方向錯誤

很多情況下， 程式效能問題跟併發處理無關， 當一個程式執行緩慢時， 並不會因為多加幾個執行緒處理就會變的很快，真正引起問題的原因往往出人意料，而且極有可能是非常低階的問題， 排除掉這些問題所在，保證程式碼健康，如果效能問題依舊存在， 再使用併發手段去解決不遲。

再者，優化程式效能必須確定造成效能問題的程式碼塊所在，不能評直覺判斷， 否者不但解決不了問題，還浪費時間。

想要學習瞭解以上技術加群【Java高階架構進階群】：854180697；本群提供免費的學習指導，架構資料以及免費的解答，不懂得問題都可以在本群提出來，之後還會有職業生涯規劃以及面試指導；進群修改群備註：開發年限-地區-經驗，方便架構師解答問題

寫在最後：歡迎留言討論，歡迎關注，持續更新！