1          簡介

日志系統是一種不可或缺的跟蹤調試工具，特別是在任何無人職守的后臺程序以及那些沒有跟蹤調試環境的系統中有著廣泛的應用。 長期以來， 日志系統作為一種應用程序服務，對于跟蹤調試、程序狀態記錄、崩潰數據恢復都有非常現實的意義。這種服務通常以兩種方式存在：

1.       日志系統作為服務進程存在。 Windows 中的的事件日志服務就屬于這種類型，該類型的日志系統通常通過消息隊列機制將所需要記錄的日志由日志發送端發送給日志服務。日志發送端和日志保存端通常不在同一進程當中，日志的發送是異步過程。這種日志服務通常用于管理員監控各種系統服務的狀態。

2.       日志系統作為系統調用存在。 Java 世界中的日志系統和 Unix 環境下諸多守護進程所使用的日志系統都屬于這種類型。日志系統的代碼作為系統調用被編譯進日志發送端，日志系統的運行和業務代碼的運行在同一進程空間。日志的發送多數屬于同步過程。這種日志服務由于能夠同步反映處系統運行狀態，通常用于調試跟蹤和崩潰恢復。

本文建立的日志系統基本屬于第二種類型，但又有所不同。該日志系統將利用 Java 線程技術實現一個既能夠反映統一線程空間中程序運行狀態的同步日志發送過程，又能夠提供快速的日志記錄服務，還能夠提供靈活的日志格式配置和過濾機制。

1.1         系統調試的誤區

在控制臺環境上調試 Java 程序時，此時往控制臺或者文本文件輸出一段文字是查看程序運行狀態最簡單的做法，但這種方式并不能解決全部的問題。有時候，對于一個我們無法實時查看系統輸出的系統或者一個確實需要保留我們輸出信息的系統，良好的日志系統顯得相當必要。

因此，不能隨意的輸出各種不規范的調試信息，這些隨意輸出的信息是不可控的，難以清除，可能為后臺監控、錯誤排除和錯誤恢復帶來相當大的阻力。

1.2         日志系統框架的基本功能

一個完備的日志系統框架通常應當包括如下基本特性：

n         所輸出的日志擁有自己的分類。這樣在調試時便于針對不同系統的不同模塊進行查詢，從而快速定位到發生日志事件的代碼。

n         日志按照某種標準分成不同級別。分級以后的日志，可以用于同一分類下的日志篩選。

n         支持多線程。日志系統通常會在多線程環境中使用，特別是在 Java 系統當中，因此作為一種系統資源，日志系統應當保證是線程安全的。

n         支持不同的記錄媒介。不同的工程項目往往對日志系統的記錄媒介要求不同，因此日志系統必須提供必要的開發接口，以保證能夠比較容易的更換記錄介質。

n         高性能。日志系統通常要提供高速的日志記錄功能以應對大系統下大請求流量下系統的正常運轉。

n         穩定性。日志系統必須是保持高度的穩定性，不能因為日志系統內部錯誤導致主要業務代碼的崩潰。

1.3         常用日志系統簡介

在 Java 世界中，以下三種日志框架比較優秀：

1)        Log4J

最早的 Java 日志框架之一，由 Apache 基金會發起，提供靈活而強大的日志記錄機制。但是其復雜的配置過程和內部概念往往令使用者望而卻步。

2)        JDK1.4 Logging Framework

繼 Log4J 之后， JDK 標準委員會將 Log4J 的基本思想吸收到 JDK 當中，在 JDK1.4 中發布了第一個日志框架接口，并提供了一個簡單實現。

3)        Commons Logging Framwork

該框架同樣是 Apache 基金會項目，其出現主要是為了使得 Java 項目能夠在 Log4J 和 JDK1.4 l Logging Framework 的使用上隨意進行切換，因此該框架提供了統一的調用接口和配置方法。

2          系統設計

由于 Log4J 得到廣泛應用，從使用者的角度考慮，本文所設計的框架，采用了部分 Log4J 的接口和概念，但內部實現則完全不同。使用 Java 實現日志框架，關鍵的技術在于前面提及的日志框架特性的內部實現，特別是：日志的分類和級別、日志分發框架的設計、日志記錄器的設計以及在設計中的高性能和高穩定性的考慮。

2.1         系統架構

日志系統框架可以分為日志記錄模塊和日志輸出模塊兩大部分。日志記錄模塊負責創建和管理日志記錄器 (Logger) ，每一個 Logger 對象負責按照不同的級別 (LoggerLevel) 接收各種記錄了日志信息的日志對象 (LogItem) ， Logger 對象首先獲取所有需要記錄的日志，并且同步地將日志分派給日志輸出模塊。日志輸出模塊則負責日志 輸出器 (Appender) 的創建和管理，以及日志的輸出。系統中允許有多個不同的日志 輸出器 ，日志 輸出器 負責將日志記錄到存儲介質當中。系統結構如下圖 1 所示：

圖 1 ，日志系統結構圖

下圖 2 使用 UML 類圖給出了日志系統的架構：

圖 2 ，日志系統框架架構圖

       在圖 2 給出的架構中， 日志記錄器 Logger 是整個日志系統框架的用戶使用接口，程序員可以通過該接口記錄日志，為了實現對日志進行分類，系統設計允許存在多個 Logger 對象，每一個 Logger 負責一類日志的記錄， Logger 類同時實現了對其對象本身的管理。 LoggerLevel 類定義了整個日志系統的級別，在客戶端創建和發送日志時，這些級別會被使用到。 Logger 對象在接收到客戶端創建和發送的日志消息時，同時將該日志消息包裝成日志系統內部所使用的日志對象 LogItem ，日志對象除了發送端所發送的消息以外，還會包裝諸如發送端類名、發送事件、發送方法名、發送行號等等。這些額外的消息對于系統的跟蹤和調試都非常有價值。包裝好的 LogItem 最終被發送給 輸出器 ，由這些 輸出 器負責將日志信息寫入最終媒介， 輸出器 的類型和個數均不固定，所有的 輸出器 通過 AppenderManager 進行管理，通常通過配置文件即可方便擴展出多個 輸出器 。

2.2         日志記錄部分的設計

如前文所述，日志記錄部分負責接收日志系統客戶端發送來的日志消息、日志對象的管理等工作。下面詳細描述了日志記錄部分的設計要點：

1.         日志記錄器的管理

系統通過保持多個 Logger 對象的方式來進行日志記錄的分類。每一個 Logger 對象代表一類日志分類。因此， Logger 對象的名稱屬性是其唯一標識，通過名稱屬性獲取一個 Logger 對象：

Logger logger = Logger.getLogger(“LoggerName”);

一般的，使用類名來作為日志記錄器的名稱，這樣做的好處在于能夠盡量減少日志記錄器命名之間的沖突（因為 Java 類使用包名），同時能夠將日志記錄分類得盡可能的精細。因此，假定有一 UserManager 類需要使用日志服務，則更一般的使用方式為：

Logger logger = Logger.getLogger(UserManager.class);

2.         日志分級的實現

按照日志目的不同，將日志的級別由低到高分成五個級別：

DEBUG        - 表示輸出的日志為一個調試信息

INFO      - 表示輸出的日志是一個系統提示

WARN   - 表示輸出的日志是一個警告信息

ERROR - 表示輸出的日志是一個系統錯誤

FATAL    - 表示輸出的日志是一個導致系統崩潰嚴重錯誤

這些日志級別定義在 LoggerLevel 接口中，被日志記錄器 Logger 在內部使用。而對于日志系統客戶端則可使用 Logger 類接口對直接調用并輸出這些級別的日志， Logger 的這些接口描述如下：

public void debug(String msg);  // 輸出調試信息

public void info(String msg);   // 輸出系統提示

public void warn(String msg);   // 輸出警告信息

public void fatal(String msg);  // 輸出系統錯誤

public void error(String msg);  // 輸出嚴重錯誤

通過對 Logger 對象上這些接口的調用，直接為日志信息賦予了級別屬性，這樣為后繼的按照不同級別進行輸出的工作奠定了基礎。

3.         日志對象信息的獲取

日志對象上包含了一條日志所具備的所有信息。通常這些信息包括：輸出日志的時間、 Java 類、類成員方法、所在行號、日志體、日志級別等等。在 JDK1.4 中可以通過在方法中拋出并且捕獲住一個異常，則在捕捉到的異常對象中已經由 JVM 自動填充好了系統調用的堆棧，在 JDK1.4 中則可以使用 java.lang.StackTraceElement 獲取到每一個堆棧項的基本信息，通過對日志客戶端輸出日志方法調用層數的推算，則可以比較容易的獲取到 StackTraceElement 對象，從而獲取到輸出日志時的 Java 類、類成員方法、所在行號等信息。在 JDK1.3 或者更早的版本中，相應的工作則必須通過將異常的堆棧信息輸出到字符串中，并分析該字符串格式得到。

2.3         日志 輸出部分 的設計

日志輸出部分的設計具有一定的難度，在本文設計的日志系統中，日志的輸出、多線程的支持、日志系統的擴展性、日志系統的效率等問題都交由日志輸出部分進行管理。

1.         日志輸出器的繼承結構

在日志的輸出部分采用了二層結構，即定義了一個抽象的日志輸出器（ AbstractLoggerAppender ） , 然后從該抽象類繼承出實際的日志輸出器。 AbstractLoggerAppender 定義了一系列的對日志進行過濾的方法，而具體輸出到存儲媒介的方法則是一個抽象方法，由子類實現。在系統中默認實現了控制臺輸出器和文件輸出器兩種，其中控制臺輸出器的實現頗為簡單。

2.         文件輸出器的內部實現

在日志記錄部分的實現中，并沒有考慮多線程、高效率等問題，因此文件輸出器必須考慮這些問題的處理。在文件輸出器內部使用 java.lang.Vector 定 義了一個線程安全的高速緩沖，所有通過日志記錄部分分派到文件輸出器的日志被直接放置到該高速緩沖當中。同時在文件輸出器內部定義一個工作線程，負責定期 將高速緩沖中的內容保存到文件，在保存的過程中同時可以進行日志文件的備份等工作。由于采用了高速緩沖的結構，很顯然日志客戶端的調用已經不再是一個同步 調用，從而不再會需要等到文件操作后才返回，提高的系統調用的速度。該原理 如圖 3 所示：

圖 3 ，文件輸出器內部結構

2.4         設計難點

通過上述設計，一個具有良好擴展能力的高性能日志系統框架就已經具有了一定的雛形。在設計過程中幾個難點問題需要進一步反思。

一、是否整個系統應當采用完全異步的結構，通過類似于消息機制的方式來進行由日志客戶端發送日志給日志系統。這種方式可以作為日志系統框架另一種運行方式，在后繼設計中加以考慮。

二、在文件輸出器中可以看到，目前雖然可以擴展多個日志輸出器，但是目前提供的抽象類中僅僅提供了對日志的過濾機制，而沒有提供的緩存機制，目前的緩存機制被放在文件輸出器中實現，因此在未來的進一步設計中，可以將文件輸出器中的緩存機制上移到抽象類當中。

2.5         設計模式

在設計過程中我們特別注意使用了數個經典的設計模式。如： Logger 對象的創建使用了工廠方法模式（ Factory Method ）、由 AbstractLoggerAppender 和 ConsoleAppender 以及 FileAppender 構成了策略模式（ Strategy ），除此以外，還大量使用了單例模式（ Singleton ）。在設計中適當運用設計模式能夠加快設計進度、提高設計質量。

3          總結

本文探討了日志系統的基本特性、實現日志系統的意義、方法和內部結構，并且給出了一種基于 Java 平臺的日志系統的詳細設計。同時也指出日志系統會向服務化、異步化的方向發展。作為一種方便的跟蹤調試、數據恢復工具，應當提倡在適當的環境下對日志系統的使用。