對比 源碼 編譯器 日誌輸出 內容 自增變量 max 日誌分割 單個

源碼：
logback-test.xml文件如下加拿大28源碼出售（www.1159880099.com）QQ1159880099 ，有2個需要我們重點關註的參數：
fileNamePattern：這裏的日誌文件名變動的部分是年月日時，外加1個文件分割自增變量，警告，年月日時的數值依賴於系統時間，自增變量依賴logback框架裏運行時的內存變量。
maxFileSize：這裏日誌文件分割的條件為日誌文件大小達到1M。
View Code

輸出日誌的源碼如下，需要註意的是：
我們用while循環輸出日誌，比正常的日誌輸出強度高許多；
我們的日誌內容是"Hello logback, line "+i。

View Code

根據源碼：
第一步，我們現在要輸出10萬條日誌到日誌文件當中，每個文件大小為1MB，如圖：
可以看到，實際的文件大小是不確定的1142KB，1152KB，都大於1MB，最後一個日誌文件因為還沒有填滿而小於1MB。這是我們要弄明白的第一個問題，為什麽日誌文件大小實際上大於我們設定的上限值？
第二步，因為我們是用main方法輸出日誌，我們再運行一遍就相當於服務器重啟一遍，這個時候我們把日誌輸出內容換成，“Hello logback, line ++++++”+i。
先看文件數量，循環次數相同，新增的日誌文件數量是6個，前面0~6個文件是第一步裏運行得到的，後面的7~12是這次生成的。
對比兩張圖裏前面7個文件0~6,6號分割文件大小發生變化我們容易理解，但是0~5這6個文件怎麽都增加了，這是我們要回答的第二個問題？

logback日誌分割問題分析：
第一個問題：為什麽日誌分割實際大小大於設定的上限值？
原因分析：
一個日誌文件分割時，有兩個操作：
比較當前日誌文件與設定值的大小，判斷是否分割；
只要還未完成分割，持續向當前日誌文件寫入日誌。
當你還在比較的時候，我已經輸出幾百米了。。。行。。。。
當判斷出日誌文件大小已經達到預定值的瞬間，日誌文件還未進行分割，而此時日誌文件仍然被寫入日誌。故正常情況下，日誌文件的實際大小通常要大於設定值的大小。
超出多少：日誌文件實際超出預定值的大小size，基本上取決於判定出日誌文件大小達到臨界值的時間點zeroPoint以後，日誌記錄的寫入相對於日誌文件創建的速度。
通常來說，日誌在代碼中的輸出越頻繁，超出臨界值越多(我們這裏的循環輸出日誌，強度是很大的)。
詭譎：JIT在作祟？多次重復以上的單個步驟，觀察日誌分割文件大小，我們不難發現，日誌文件列表的開頭幾個文件總是比後面的日誌文件要小一些。換句話說，運行時的日誌輸出速度發生了變化，我猜想這裏極有可能是因為while循環被JIT編譯器檢測到為熱點代碼，所以進行了再編譯，從而使日誌的輸出速度變得更快，導致後面的日誌文件更大些。
第二個問題：為什麽“重啟”後，原本應該鎖定的日誌文件，再次被輸入日誌？
證據：檢查0~6號文件的末尾，我們都可以發現“Hello logback, line ++++++”+i，這段記錄的存在。也就是說，“重啟”之前的、按理說已經“滿格”達到上限值日誌文件，在“重啟”後，發生了日誌再次寫入的問題。
原因分析：
日誌名稱：test-log.2018-08-14-13.0.log。文件名稱精確到小時，我們“重啟”前後，都是在同一天的13點！
日誌名稱的變化依賴於時間，以及分割序號，時間由操作系統決定，分割序號由logback框架決定。分割序號對應的變量值是沒有持久化的！一旦重啟，就只能重頭開始，所以在同一個時間段(這裏是同一天的同一個小時)裏發生重啟，不會新建日誌文件，而是在原有的日誌裏追加記錄；
第一個問題裏已經說了，日所以誌文件在比較的時候(還未比較完成時)，仍然在進行日誌輸出，所以日誌文件會變大。

logback框架之——日誌加拿大28源碼出售分割所帶來的潛在問題