建站
咨詢
售后
建站咨詢
新聞中心
概述
為青川等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及青川網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、青川網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
日志技術(shù)為產(chǎn)品的質(zhì)量和服務(wù)提供了重要的支撐。JDK 在 1.4 版本以后加入了日志機制，為 Java 開發(fā)人員提供了便利。但這種日志機制是基于靜態(tài)日志級別的，也就是在程序運行前就需設(shè)定下來要打印的日志級別，這樣就會帶來一些不便。
在 JDK 提供的日志功能中，日志級別被細(xì)化為 9 級，用以區(qū)分不同日志的用途，用來記錄一個錯誤，或者記錄正常運行的信息，又或是記錄詳細(xì)的調(diào)試信息。由于日志級別是靜態(tài)的，如果日志級別設(shè)定過高，低級 別的日志難以打印出來，從而導(dǎo)致在錯誤發(fā)生時候，難以去追蹤錯誤的發(fā)生原因，目前常常采用的方式是在錯誤發(fā)生的時候，不得不先調(diào)整日志級別到相對低的程 度，然后再去觸發(fā)錯誤，使得問題根源得到顯現(xiàn)。但是這種發(fā)生問題需要改動產(chǎn)品配置，然后重新觸發(fā)問題進(jìn)行調(diào)試的方式使得產(chǎn)品用戶體驗變差，而且有些問題會 因為偶發(fā)性，環(huán)境很復(fù)雜等原因很難重新觸發(fā)。
相反，如果起初就把日志級別調(diào)整到比較低，那么日志中間會有大量無用信息，而且當(dāng)產(chǎn)品比較復(fù)雜的時候，會導(dǎo)致產(chǎn)生的日志文件很大，刷新很快，無法及時的記錄有效的信息，甚至成為性能瓶頸，從而降低了日志功能對產(chǎn)品的幫助。
本文借助 Java Logging 中的 MemoryHandler 類將所有級別日志緩存起來，在適當(dāng)時刻輸出，來解決這個問題。主要圍繞 MemoryHandler 的定義和logging.properties 文件的處理而展開。
實例依附的場景如下，設(shè)想用戶需要在產(chǎn)品發(fā)生嚴(yán)重錯誤時，查看先前發(fā)生的包含 Exception 的錯誤信息，以此作為診斷問題緣由的依據(jù)。使用 Java 緩沖機制作出的一個解決方案是，將所有產(chǎn)品運行過程中產(chǎn)生的包含Exception 的日志條目保存在一個可設(shè)定大小的循環(huán)緩沖隊列中，當(dāng)嚴(yán)重錯誤（SEVERE）發(fā)生時，將緩沖隊列中的日志輸出到指定平臺，供用戶查閱。
Java 日志機制的介紹
Java 日志機制在很多文章中都有介紹，為了便于后面文章部分的理解，在這里再簡單介紹一下本文用到的一些關(guān)鍵字。
Level：JDK 中定義了 Off、Severe、Warning、Info、Config、Fine、Finer、Finest、All 九個日志級別，定義 Off 為日志***等級，All 為***等級。每條日志必須對應(yīng)一個級別。級別的定義主要用來對日志的嚴(yán)重程度進(jìn)行分類，同時可以用于控制日志是否輸出。
LogRecord：每一條日志會被記錄為一條 LogRecord, 其中存儲了類名、方法名、線程 ID、打印的消息等等一些信息。
Logger：日志結(jié)構(gòu)的基本單元。Logger 是以樹形結(jié)構(gòu)存儲在內(nèi)存中的，根節(jié)點為 root。com.test（如果存在）一定是 com.test.demo（如果存在）的父節(jié)點，即前綴匹配的已存在的 logger 一定是這個 logger 的父節(jié)點。這種父子關(guān)系的定義，可以為用戶提供更為自由的控制粒度。因為子節(jié)點中如果沒有定義處理規(guī)則，如級別 handler、formatter 等，那么默認(rèn)就會使用父節(jié)點中的這些處理規(guī)則。
Handler：用來處理 LogRecord，默認(rèn) Handler 是可以連接成一個鏈狀，依次對 LogRecord 進(jìn)行處理。
Filter：日志過濾器。在 JDK 中，沒有實現(xiàn)。
Formatter：它主要用于定義一個 LogRecord 的輸出格式。
圖 1. Java 日志處理流程
圖 1 展示了一個 LogRecord 的處理流程。一條日志進(jìn)入處理流程首先是 Logger，其中定義了可通過的 Level，如果 LogRecord 的 Level 高于Logger 的等級，則進(jìn)入 Filter（如果有）過濾。如果沒有定義 Level，則使用父 Logger 的 Level。Handler 中過程類似，其中 Handler 也定義了可通過 Level，然后進(jìn)行 Filter 過濾，通過如果后面還有其他 Handler，則直接交由后面的 Handler 進(jìn)行處理，否則會直接綁定到 formatter 上面輸出到指定位置。
在實現(xiàn)日志緩存之前，先對 Filter 和 Formatter 兩個輔助類進(jìn)行介紹。
Filter
Filter 是一個接口，主要是對 LogRecord 進(jìn)行過濾，控制是否對 LogRecord 進(jìn)行進(jìn)一步處理，其可以綁定在 Logger 下或 Handler 下。
只要在 boolean isLoggable（LogRecord）方法中加上過濾邏輯就可以實現(xiàn)對 logrecord 進(jìn)行控制，如果只想對發(fā)生了 Exception 的那些 log 記錄進(jìn)行記錄，那么可以通過清單 1 來實現(xiàn)，當(dāng)然首先需要將該 Filter 通過調(diào)用 setFilter（Filter）方法或者配置文件方式綁定到對應(yīng)的 Logger 或 Handler。
清單 1. 一個 Filter 實例的實現(xiàn)
- Override
- public boolean isLoggable(LogRecord record){
- if(record.getThrown()!=null){
- return true;
- }else{
- return false;
- }
- }
Formatter
Formatter 主要是對 Handler 在輸出 log 記錄的格式進(jìn)行控制，比如輸出日期的格式，輸出為 HTML 還是 XML 格式，文本參數(shù)替換等。Formatter 可以綁定到 Handler 上，Handler 會自動調(diào)用 Formatter 的 String format（LogRecord r） 方法對日志記錄進(jìn)行格式化，該方法具有默認(rèn)的實現(xiàn)，如果想實現(xiàn)自定義格式可以繼承 Formater 類并重寫該方法，默認(rèn)情況下例如清單 2 在經(jīng)過 Formatter 格式化后，會將 {0} 和 {1} 替換成對應(yīng)的參數(shù)。
清單 2. 記錄一條 log
- logger.log(Level.WARNING,"this log is for test1: {0} and test2:{1}",
- new Object[]{newTest1(),
- new Test2()});
MemoryHandler
MemoryHandler 是 Java Logging 中兩大類 Handler 之一，另一類是 StreamHandler，二者直接繼承于 Handler，代表了兩種不同的設(shè)計思路。Java Logging Handler 是一個抽象類，需要根據(jù)使用場景創(chuàng)建具體 Handler，實現(xiàn)各自的 publish、flush 以及 close 等方法。
MemoryHandler 使用了典型的“注冊 – 通知”的觀察者模式。MemoryHandler 先注冊到對自己感興趣的 Logger 中（logger.addHandler(handler)），在這些 Logger 調(diào)用發(fā)布日志的 API：log()、logp()、logrb() 等，遍歷這些 Logger 下綁定的所有 Handlers 時，通知觸發(fā)自身 publish（LogRecord）方法的調(diào)用，將日志寫入 buffer，當(dāng)轉(zhuǎn)儲到下一個日志發(fā)布平臺的條件成立，轉(zhuǎn)儲日志并清空 buffer。
這里的 buffer 是 MemoryHandler 自身維護一個可自定義大小的循環(huán)緩沖隊列，來保存所有運行時觸發(fā)的 Exception 日志條目。同時在構(gòu)造函數(shù)中要求指定一個 Target Handler，用于承接輸出；在滿足特定 flush buffer 的條件下，如日志條目等級高于 MemoryHandler 設(shè)定的 push level 等級（實例中定義為 SEVERE）等，將日志移交至下一步輸出平臺。從而形成如下日志轉(zhuǎn)儲輸出鏈：
圖 2. Log 轉(zhuǎn)儲鏈
在實例中，通過對 MemoryHandler 配置項 .push 的 Level 進(jìn)行判斷，決定是否將日志推向下一個 Handler，通常在 publish() 方法內(nèi)實現(xiàn)。代碼清單如下：
#p#
清單 3
- // 只紀(jì)錄有異常并且高于 pushLevel 的 logRecord
- final Level level = record.getLevel();
- final Throwable thrown = record.getThrown();
- If(level >= pushLevel){
- push();
- }
MemoryHandler.push 方法的觸發(fā)條件
Push 方法會導(dǎo)致 MemoryHandler 轉(zhuǎn)儲日志到下一 handler，清空 buffer。觸發(fā)條件可以是但不局限于以下幾種，實例中使用的是默認(rèn)的***種：
- 日志條目的 Level 大于或等于當(dāng)前 MemoryHandler 中默認(rèn)定義或用戶配置的 pushLevel；
- 外部程序調(diào)用 MemoryHandler 的 push 方法；
- MemoryHandler 子類可以重載 log 方法或自定義觸發(fā)方法，在方法中逐一掃描日志條目，滿足自定義規(guī)則則觸發(fā)轉(zhuǎn)儲日志和清空 buffer 的操作。MemoryHanadler 的可配置屬性
表 1.MemoryHandler 可配置屬性
| 屬性名 | 描述 | 缺省值 | |
|---|---|---|---|
| 繼承屬性 | MemoryHandler.level | MemoryHandler 接受的輸入到 buffer 的日志等級 | Level.INFO |
| MemoryHandler.filter | 在輸入到 buffer 之前，可在 filter 中自定義除日志等級外的其他過濾條件 | (Undefined) | |
| MemoryHandler.formatter | 指定輸入至 buffer 的日志格式 | (Undefined) | |
| MemoryHandler.encoding | 指定輸入至 buffer 的日志編碼，在 MemoryHandler 中應(yīng)用甚少 | (Undefined) | |
| 私有屬性 | MemoryHandler.size | 以日志條目為單位定義循環(huán) buffer 的大小 | 1,000 |
| MemoryHandler.push | 定義將 buffer 中的日志條目發(fā)送至下一個 Handler 的*** Level（包含） | Level.SEVERE | |
| MemoryHandler.target | 在構(gòu)造函數(shù)中指定下一步承接日志的 Handler | (Undefined) |
使用方式：
以上是記錄產(chǎn)品 Exception 錯誤日志，以及如何轉(zhuǎn)儲的 MemoryHandler 處理的內(nèi)部細(xì)節(jié)；接下來給出 MemoryHandler 的一些使用方式。
1. 直接使用 java.util.logging 中的 MemoryHandler
清單4
- // 在 buffer 中維護 5 條日志信息
- // 僅記錄 Level 大于等于 Warning 的日志條目并
- // 刷新 buffer 中的日志條目到 fileHandler 中處理
- int bufferSize = 5;
- f = new FileHandler("testMemoryHandler.log");
- m = new MemoryHandler(f, bufferSize, Level.WARNING);
- …
- myLogger = Logger.getLogger("com.ibm.test");
- myLogger.addHandler(m);
- myLogger.log(Level.WARNING, “this is a WARNING log”);
. 自定義
1）反射
思考自定義 MyHandler 繼承自 MemoryHandler 的場景，由于無法直接使用作為父類私有屬性的 size、buffer 及 buffer 中的 cursor，如果在 MyHandler 中有獲取和改變這些屬性的需求，一個途徑是使用反射。清單 5 展示了使用反射讀取用戶配置并設(shè)置私有屬性。
清單5
- int m_size;
- String sizeString = manager.getProperty(loggerName + ".size");
- if (null != sizeString) {
- try {
- m_size = Integer.parseInt(sizeString);
- if (m_size <= 0) {
- m_size = BUFFER_SIZE; // default 1000
- }
- // 通過 java 反射機制獲取私有屬性
- Field f;
- f = getClass().getSuperclass().getDeclaredField("size");
- f.setAccessible(true);
- f.setInt(this, m_size);
- f = getClass().getSuperclass().getDeclaredField("buffer");
- f.setAccessible(true);
- f.set(this, new LogRecord[m_size]);
- } catch (Exception e) {
- }
- }
2）重寫
直接使用反射方便快捷，適用于對父類私有屬性無頻繁訪問的場景。思考這樣一種場景，默認(rèn)環(huán)形隊列無法滿足我們存儲需求，此時不妨令自定義的 MyMemoryHandler 直接繼承 Handler，直接對存儲結(jié)構(gòu)進(jìn)行操作，可以通過清單 6 實現(xiàn)。
清單 6
- public class MyMemoryHandler extends Handler{
- // 默認(rèn)存儲 LogRecord 的緩沖區(qū)容量
- private static final int DEFAULT_SIZE = 1000;
- // 設(shè)置緩沖區(qū)大小
- private int size = DEFAULT_SIZE;
- // 設(shè)置緩沖區(qū)
- private LogRecord[] buffer;
- // 參考 java.util.logging.MemoryHandler 實現(xiàn)其它部分
- ...
- }
使用 MemoryHandler 時需關(guān)注的幾個問題
了解了使用 MemoryHandler 實現(xiàn)的 Java 日志緩沖機制的內(nèi)部細(xì)節(jié)和外部應(yīng)用之后，來著眼于兩處具體實現(xiàn)過程中遇到的問題：Logger/Handler/LogRecord Level 的傳遞影響，以及如何在開發(fā) MemoryHandler 過程中處理錯誤日志。
1. Level 的傳遞影響
Java.util.logging 中有三種類型的 Level，分別是 Logger 的 Level，Handler 的 Level 和 LogRecord 的 Level. 前兩者可以通過配置文件設(shè)置。之后將日志的 Level 分別與 Logger 和 Handler 的 Level 進(jìn)行比較，過濾無須記錄的日志。在使用 Java Log 時需關(guān)注 Level 之間相互影響的問題，尤其在遍歷 Logger 綁定了多個 Handlers 時。如圖 3 所示：
圖 3. Java Log 中 Level 的傳遞影響
Java.util.logging.Logger 提供的 setUseParentHandlers 方法，也可能會影響到最終輸出終端的日志顯示。這個方法允許用戶將自身的日志條目打印一份到 Parent Logger 的輸出終端中。缺省會打印到 Parent Logger 終端。此時，如果 Parent Logger Level 相關(guān)的設(shè)置與自身 Logger 不同，則打印到 Parent Logger 和自身中的日志條目也會有所不同。如圖 4 所示：
圖 4. 子類日志需打印到父類輸出終端
2. 開發(fā) log 接口過程中處理錯誤日志
在開發(fā) log 相關(guān)接口中調(diào)用自身接口打印 log，可能會陷入無限循環(huán)。Java.util.logging 中考慮到這類問題，提供了一個 ErrorManager 接口，供 Handler 在記錄日志期間報告任何錯誤，而非直接拋出異?；蛘{(diào)用自身的 log 相關(guān)接口記錄錯誤或異常。Handler 需實現(xiàn) setErrorManager() 方法，該方法為此應(yīng)用程序構(gòu)造 java.util.logging.ErrorManager 對象，并在錯誤發(fā)生時，通過 reportError 方法調(diào)用 ErrorManager 的 error 方法，缺省將錯誤輸出到標(biāo)準(zhǔn)錯誤流，或依據(jù) Handler 中自定義的實現(xiàn)處理錯誤流。關(guān)閉錯誤流時，使用 Logger.removeHandler 移除此 Handler 實例。
兩種經(jīng)典使用場景，一種是自定義 MyErrorManager，實現(xiàn)父類相關(guān)接口，在記錄日志的程序中調(diào)用 MyHandler.setErrorManager(new MyEroorManager()); 另一種是在 Handler 中自定義 ErrorManager 相關(guān)方法，示例如清單 7：
#p#
清單 7
- public class MyHandler extends Handler{
- // 在構(gòu)造方法中實現(xiàn) setErrorManager 方法
- public MyHandler(){
- ......
- setErrorManager (new ErrorManager() {
- public void error (String msg, Exception ex, int code) {
- System.err.println("Error reported by MyHandler "
- + msg + ex.getMessage());
- }
- });
- }
- public void publish(LogRecord record){
- if (!isLoggable(record)) return;
- try {
- // 一些可能會拋出異常的操作
- } catch(Exception e) {
- reportError ("Error occurs in publish ", e, ErrorManager.WRITE_FAILURE);
- }
- }
- ......
- }
logging.properties
logging.properties 文件是 Java 日志的配置文件，每一行以“key=value”的形式描述，可以配置日志的全局信息和特定日志配置信息，清單 8 是我們?yōu)闇y試代碼配置的 logging.properties。
清單 8. logging.properties 文件示例
- #Level 等級 OFF > SEVERE > WARNING > INFO > CONFIG > FINE > FINER > FINEST > ALL
- # 為 FileHandler 指定日志級別
- java.util.logging.FileHandler.level=WARNING
- # 為 FileHandler 指定 formatter
- java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
- # 為自定義的 TestMemoryHandler 指定日志級別
- com.ibm.test.MemoryHandler.level=INFO
- # 設(shè)置 TestMemoryHandler 最多記錄日志條數(shù)
- com.ibm.test.TestMemoryHandler.size=1000
- # 設(shè)置 TestMemoryHandler 的自定義域 useParentLevel
- com.ibm.test.TestMemoryHandler.useParentLevel=WARNING
- # 設(shè)置特定 log 的 handler 為 TestMemoryHandler
- com.ibm.test.handlers=com.ibm.test.TestMemoryHandler
- # 指定全局的 Handler 為 FileHandler
- handlers=java.util.logging.FileHandler
從 清單 8 中可以看出 logging.properties 文件主要是用來給 logger 指定等級（level），配置 handler 和 formatter 信息。
如何監(jiān)聽 logging.properties
如果一個系統(tǒng)對安全性要求比較高，例如系統(tǒng)需要對更改 logging.properties 文件進(jìn)行日志記錄，記錄何時何人更改了哪些記錄，那么應(yīng)該怎么做呢？
這里可以利用 JDK 提供的 PropertyChangeListener 來監(jiān)聽 logging.properties 文件屬性的改變。
例如創(chuàng)建一個 LogPropertyListener 類，其實現(xiàn)了 java.benas.PropertyChangeListener 接口，PropertyChangeListener 接口中只包含一個 propertyChange（PropertyChangeEvent）方法，該方法的實現(xiàn)如清 9 所示。
清單 9. propertyChange 方法的實現(xiàn)
- @Override
- public void propertyChange(PropertyChangeEvent event) {
- if (event.getSource() instanceof LogManager){
- LogManager manager=(LogManager)event.getSource();
- update(manager);
- execute();
- reset();
- }
- }
propertyChange（PropertyChangeEvent）方法中首先調(diào)用 update（LogManager）方法來找出 logging.properties 文件中更改的，增加的以及刪除的項，這部分代碼如清單 10 所示；然后調(diào)用 execute() 方法來執(zhí)行具體邏輯，參見 清單 11；***調(diào)用 reset() 方法對相關(guān)屬性保存以及清空，如 清單 12 所示。
清單 10. 監(jiān)聽改變的條目
- public void update(LogManager manager){
- Properties logProps = null ;
- // 使用 Java 反射機制獲取私有屬性
- try {
- Field f = manager.getClass().getDeclaredField("props");
- f.setAccessible(true );
- logProps=(Properties)f.get(manager);
- }catch (Exception e){
- logger.log(Level.SEVERE,"Get private field error.", e);
- return ;
- }
- Set
logPropsName=logProps.stringPropertyNames(); - for (String logPropName:logPropsName){
- String newVal=logProps.getProperty(logPropName).trim();
- // 記錄當(dāng)前的屬性
- newProps.put(logPropName, newVal);
- // 如果給屬性上次已經(jīng)記錄過
- if (oldProps.containsKey(logPropName)){
- String oldVal = oldProps.get(logPropName);
- if (newVal== null ?oldVal== null :newVal.equals(oldVal)){
- // 屬性值沒有改變，不做任何操作
- }else {
- changedProps.put(logPropName, newVal);
- }
- oldProps.remove(logPropName);
- }else {// 如果上次沒有記錄過該屬性，則其應(yīng)為新加的屬性，記錄之
- changedProps.put(logPropName, newVal);
- }
- }
- }
代碼中 oldProps、newProps 以及 changedProps 都是 HashMap類型，oldProps 存儲修改前 logging.properties 文件內(nèi)容，newProps 存儲修改后 logging.properties 內(nèi)容，changedProps 主要用來存儲增加的或者是修改的部分。
方法首先通過 Java 的反射機制獲得 LogManager 中的私有屬性 props（存儲了 logging.properties 文件中的屬性信息），然后通過與 oldProps 比較可以得到增加的以及修改的屬性信息，*** oldProps 中剩下的就是刪除的信息了。
#p#
清單 11. 具體處理邏輯方法
- private void execute(){
- // 處理刪除的屬性
- for (String prop:oldProps.keySet()){
- // 這里可以加入其它處理步驟
- logger.info("'"+prop+"="+oldProps.get(prop)+"'has been removed");
- }
- // 處理改變或者新加的屬性
- for (String prop:changedProps.keySet()){
- // 這里可以加入其它處理步驟
- logger.info("'"+prop+"="+oldProps.get(prop)+"'has been changed or added");
- }
- }
該方法是主要的處理邏輯，對修改或者刪除的屬性進(jìn)行相應(yīng)的處理，比如記錄屬性更改日志等。這里也可以獲取當(dāng)前系統(tǒng)的登錄者，和當(dāng)前時間，這樣便可以詳細(xì)記錄何人何時更改過哪個日志條目。
清單 12. 重置所有數(shù)據(jù)結(jié)構(gòu)
- private void reset(){
- oldProps = newProps;
- newProps= new HashMap< String,String>();
- changedProps.clear();
- }
eset() 方法主要是用來重置各個屬性，以便下一次使用。
當(dāng)然如果只寫一個 PropertyChangeListener 還不能發(fā)揮應(yīng)有的功能，還需要將這個 PropertyChangeListener 實例注冊到 LogManager 中，可以通過清單 13 實現(xiàn)。
清單 13. 注冊 PropertyChangeListener
- // 為'logging.properties'文件注冊監(jiān)聽器
- LogPropertyListener listener= new LogPropertyListener();
- LogManager.getLogManager().addPropertyChangeListener(listener);
如何實現(xiàn)自定義標(biāo)簽
在 清單 8中有一些自定義的條目，比如 com.ibm.test.TestMemoryHandler。
useParentLever=WARNING”，表示如果日志等級超過 useParentLever 所定義的等級 WARNING 時，該條日志在 TestMemoryHandler 處理后需要傳遞到對應(yīng) Log 的父 Log 的 Handler 進(jìn)行處理（例如將發(fā)生了 WARNING 及以上等級的日志上下文緩存信息打印到文件中），否則不傳遞到父 Log 的 Handler 進(jìn)行處理，這種情況下如果不做任何處理，Java 原有的 Log 機制是不支持這種定義的。那么如何使得 Java Log 支持這種自定義標(biāo)簽?zāi)?？這里可以使用 PropertyListener 對自定義標(biāo)簽進(jìn)行處理來使得 Java Log 支持這種自定義標(biāo)簽，例如對“useParentLever”進(jìn)行處理可以通過清單 14 實現(xiàn)。
清單 14
- private void execute(){
- // 處理刪除的屬性
- for (String prop:oldProps.keySet()){
- if (prop.endsWith(".useParentLevel")){
- String logName=prop.substring(0, prop.lastIndexOf("."));
- Logger log=Logger.getLogger(logName);
- for (Handler handler:log.getHandlers()){
- if (handler instanceof TestMemoryHandler){
- ((TestMemoryHandler)handler)
- .setUseParentLevel(oldProps.get(prop));
- break ;
- }
- }
- }
- }
- // 處理改變或者新加的屬性
- for (String prop:changedProps.keySet()){
- if (prop.endsWith(".useParentLevel")){
- // 在這里添加邏輯處理步驟
- }
- }
- }
在清單 14 處理之后，就可以在自定義的 TestMemoryHandler 中進(jìn)行判斷了，對 log 的等級與其域 useParentLevel 進(jìn)行比較，決定是否傳遞到父 Log 的 Handler 進(jìn)行處理。在自定義 TestMemoryHandler 中保存對應(yīng)的 Log 信息可以很容易的實現(xiàn)將信息傳遞到父 Log 的 Handler，而保存對應(yīng) Log 信息又可以通過 PropertyListener 來實現(xiàn)，例如清單 15 更改了 清單 13中相應(yīng)代碼實現(xiàn)這一功能。
清單 15
- if (handler instanceof TestMemoryHandler){
- ((TestMemoryHandler)handler).setUseParentLevel(oldProps.get(prop));
- ((TestMemoryHandler)handler).addLogger(log);
- break ;
- }
具體如何處理自定義標(biāo)簽的值那就看程序的需要了，通過這種方法就可以很容易在 logging.properties 添加自定義的標(biāo)簽了。
自定義讀取配置文件
如果 logging.properties 文件更改了，需要通過調(diào)用 readConfiguration（InputStream）方法使更改生效，但是從 JDK 的源碼中可以看到 readConfiguration（InputStream）方法會重置整個 Log 系統(tǒng)，也就是說會把所有的 log 的等級恢復(fù)為默認(rèn)值，將所有 log 的 handler 置為 null 等，這樣所有存儲的信息就會丟失。
比如，TestMemoryHandler 緩存了 1000 條 logRecord，現(xiàn)在用戶更改了 logging.properties 文件，并且調(diào)用了 readConfiguration（InputStream） 方法來使之生效，那么由于 JDK 本身的 Log 機制，更改后對應(yīng) log 的 TestMemoryHandler 就是新創(chuàng)建的，那么原來存儲的 1000 條 logRecord 的 TestMemoryHandler 實例就會丟失。
那么這個問題應(yīng)該如何解決呢？這里給出三種思路：
1). 由于每個 Handler 都有一個 close() 方法（任何繼承于 Handler 的類都需要實現(xiàn)該方法），Java Log 機制在將 handler 置為 null 之前會調(diào)用對應(yīng) handler 的 close() 方法，那么就可以在 handler（例如 TestMemoryHandler）的 close() 方法中保存下相應(yīng)的信息。
2). 研究 readConfiguration（InputStream）方法，寫一個替代的方法，然后每次調(diào)用替代的方法。
3). 繼承 LogManager 類，覆蓋 readConfiguration（InputStream）方法。
這里***種方法是保存原有的信息，然后進(jìn)行恢復(fù)，但是這種方法不是很實用和高效；第二和第三種方法其實是一樣的，都是寫一個替代的方法，例如可以在 替代的方法中對 Handler 為 TestMemoryHandler 的不置為 null，然后在讀取 logging.properties 文件時發(fā)現(xiàn)為 TestMemoryHandler 屬性時，找到對應(yīng) TestMemoryHandler 的實例，并更改相應(yīng)的屬性值（這個在清單 14 中有所體現(xiàn)），其他不屬于 TestMemoryHandler 屬性值的可以按照 JDK 原有的處理邏輯進(jìn)行處理，比如設(shè)置 log 的 level 等。
另一方面，由于 JDK1.6 及之前版本不支持文件修改監(jiān)聽功能，每次修改了 logging.properties 文件后需要顯式調(diào)用 readConfiguration（InputStream）才能使得修改生效，但是自 JDK1.7 開始已經(jīng)支持對文件修改監(jiān)聽功能了，主要是在 java.nio.file.* 包中提供了相關(guān)的 API，這里不再詳述。
那么在 JDK1.7 之前，可以使用 apache 的 commons-io 庫中的 FileMonitor 類，在此也不再詳述。
總結(jié)
通過對 MemoryHandler 和 logging.properties 進(jìn)行定義，可以通過 Java 日志實現(xiàn)自定義日志緩存，從而提高 Java 日志的可用性，為產(chǎn)品質(zhì)量提供更強有力的支持。
原文鏈接：http://blog.jobbole.com/44668/
分享名稱：Java日志緩存機制的實現(xiàn)
文章來源：http://m.fisionsoft.com.cn/article/cdihjho.html
