java.util.logging.Logger基礎教程

@(JAVA)[java]

從JDK1.4開始即引入與日志相關的類java.util.logging.Logger，但由于Log4J的存在，一直未能廣泛使用。綜合網上各類說法，大致認為：
（1）Logger：適用于小型系統，當日志量過大時性能有待提升。好處在于JDK集成了此類，無需引入新包。且性能也在逐步改善當中，我認為一般而言，使用Logger即可。
（2）Log4J：并發性較好，性能較強，適用于大型系統。
本文介紹java.util.logging.Logger的詳細用法。

1、基本概念

Logger中有2個比較重要的概念，分別是記錄器(Logger)與處理器(Handler)，二者分別完成以下功能：
（1）Logger：記錄日志，設置日志級別等。
（2）Handler：確定輸出位置等。

2、Logger相關

（1）一般通過getLogger來獲取對象，而不能通過構造函數直接構造。

static Logger getLogger(String name) static Logger getLogger(String name, String resourceBundleName)

Logger objects may be obtained by calls on one of the getLogger factory methods. These will either create a new Logger or return a suitable existing Logger.由于是通過工作獲取到的對象，因此，若所傳參數相同，則會返回同一個Logger對象。

（2）關于Logger的命名
Logger names can be arbitrary strings, but they should normally be based on the package name or class name of the logged component, such as java.net or javax.swing.
Logger原則上可以任意命名，但實際上一般是與Logger所在包或者所有類的名稱相同。
（3）Logger的級別

SEVERE（最高值） WARNING INFO CONFIG FINE FINER FINEST（最低值）

此外，還有一個級別 OFF，可用來關閉日志記錄，使用級別 ALL 啟用所有消息的日志記錄。
logger默認的級別是INFO，比INFO更低的日志將不顯示。通過此屬性，可以簡單的修改Logger的級別，以達到開關日志的目的。
（4）Logger是具有層級關系的，比如org.abc.def會繼承org.abc的一些屬性。

3、Handler相關
（1）Handler 對象從 Logger 中獲取日志信息，并將這些信息導出。例如，它可將這些信息寫入控制臺或文件中，也可以將這些信息發送到網絡日志服務中，或將其轉發到操作系統日志中。
（2）可通過執行 setLevel(Level.OFF) 來禁用 Handler，并可通過執行適當級別的 setLevel 來重新啟用。
（3）默認情況下，使用ConsoleHandler，即將日志輸出至控制臺。可通過FileHandler，SocketHandler等，將日志導向其它地方。

4、基本示例
（1）輸出至控制臺

public static void main(String[] args) {final Logger logger = Logger.getLogger("org.jediael.crawl.MyCrawler");logger.info("Begin Crawling, Good Luck!");//為每一個種子url，啟動一個線程Thread t = new Thread(new Runnable() {@Overridepublic void run() {logger.info(Thread.currentThread()+" start!!");

控制臺輸出如下：

六月 18, 2014 2:49:35 下午 org.jediael.crawl.MyCrawler main 信息: Begin Crawling, Good Luck! 六月 18, 2014 2:49:35 下午 org.jediael.crawl.MyCrawler$2 run 信息: Thread[Thread-1,5,main] start!! 六月 18, 2014 2:49:35 下午 org.jediael.crawl.MyCrawler$2 run 信息: Thread[Thread-4,5,main] start!! 六月 18, 2014 2:49:35 下午 org.jediael.crawl.MyCrawler$2 run 信息: Thread[Thread-3,5,main] start!! 六月 18, 2014 2:49:35 下午 org.jediael.crawl.MyCrawler$2 run 信息: Thread[Thread-2,5,main] start!!

（2）改變logger的級別
默認情況下，logger的級別為Info，它會處理info及其以上級別的日志；若將其提高至waring,則示例1中的日志將不再顯示。

public static void main(String[] args) {final Logger logger = Logger.getLogger("org.jediael.crawl.MyCrawler");logger.setLevel(Level.WARNING);logger.info("Begin Crawling, Good Luck!");

此時控制臺無輸出

（3）將日志輸出至文件

final Logger logger = Logger.getLogger("org.jediael.crawl.MyCrawler");logger.setLevel(Level.INFO);FileHandler fileHandler = new FileHandler("d:\\1.log");fileHandler.setLevel(Level.INFO);logger.addHandler(fileHandler);logger.info("Begin Crawling, Good Luck!");

此時日志同時輸出至控制臺及文件中。注意，未指定文件格式的情況下，日志輸出格式為XML。

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE log SYSTEM "logger.dtd"> <log> <record><date>2014-06-18T15:04:44</date><millis>1403075084407</millis><sequence>0</sequence><logger>org.jediael.crawl.MyCrawler</logger><level>INFO</level><class>org.jediael.crawl.MyCrawler</class><method>main</method><thread>1</thread><message>Begin Crawling, Good Luck!</message> </record> <record><date>2014-06-18T15:04:44</date><millis>1403075084471</millis><sequence>1</sequence>

若需要改變日志的輸出格式，則需要使用Formatter。
如何才能只將日志輸出到文件，而不輸出至Console？
加上以下語句即可移除console中的輸出。

logger.setUseParentHandlers(false);

附API文檔說明：
A Logger object is used to log messages for a specific system or application component. Loggers are normally named, using a hierarchical dot-separated namespace. Logger names can be arbitrary strings, but they should normally be based on the package name or class name of the logged component, such as java.net or javax.swing. In addition it is possible to create “anonymous” Loggers that are not stored in the Logger namespace.

Logger objects may be obtained by calls on one of the getLogger factory methods. These will either create a new Logger or return a suitable existing Logger. It is important to note that the Logger returned by one of the getLogger factory methods may be garbage collected at any time if a strong reference to the Logger is not kept.

Logging messages will be forwarded to registered Handler objects, which can forward the messages to a variety of destinations, including consoles, files, OS logs, etc.

Each Logger keeps track of a “parent” Logger, which is its nearest existing ancestor in the Logger namespace.

Each Logger has a “Level” associated with it. This reflects a minimum Level that this logger cares about. If a Logger’s level is set to null, then its effective level is inherited from its parent, which may in turn obtain it recursively from its parent, and so on up the tree.

The log level can be configured based on the properties from the logging configuration file, as described in the description of the LogManager class. However it may also be dynamically changed by calls on the Logger.setLevel method. If a logger’s level is changed the change may also affect child loggers, since any child logger that has null as its level will inherit its effective level from its parent.

On each logging call the Logger initially performs a cheap check of the request level (e.g., SEVERE or FINE) against the effective log level of the logger. If the request level is lower than the log level, the logging call returns immediately.

After passing this initial (cheap) test, the Logger will allocate a LogRecord to describe the logging message. It will then call a Filter (if present) to do a more detailed check on whether the record should be published. If that passes it will then publish the LogRecord to its output Handlers. By default, loggers also publish to their parent’s Handlers, recursively up the tree.

Each Logger may have a ResourceBundle name associated with it. The named bundle will be used for localizing logging messages. If a Logger does not have its own ResourceBundle name, then it will inherit the ResourceBundle name from its parent, recursively up the tree.

Most of the logger output methods take a “msg” argument. This msg argument may be either a raw value or a localization key. During formatting, if the logger has (or inherits) a localization ResourceBundle and if the ResourceBundle has a mapping for the msg string, then the msg string is replaced by the localized value. Otherwise the original msg string is used. Typically, formatters use java.text.MessageFormat style formatting to format parameters, so for example a format string “{0} {1}” would format two parameters as strings.

When mapping ResourceBundle names to ResourceBundles, the Logger will first try to use the Thread’s ContextClassLoader. If that is null it will try the SystemClassLoader instead. As a temporary transition feature in the initial implementation, if the Logger is unable to locate a ResourceBundle from the ContextClassLoader or SystemClassLoader the Logger will also search up the class stack and use successive calling ClassLoaders to try to locate a ResourceBundle. (This call stack search is to allow containers to transition to using ContextClassLoaders and is likely to be removed in future versions.)

Formatting (including localization) is the responsibility of the output Handler, which will typically call a Formatter.

Note that formatting need not occur synchronously. It may be delayed until a LogRecord is actually written to an external sink.

The logging methods are grouped in five main categories:

There are a set of "log" methods that take a log level, a message string, and optionally some parameters to the message string.There are a set of "logp" methods (for "log precise") that are like the "log" methods, but also take an explicit source class name and method name.There are a set of "logrb" method (for "log with resource bundle") that are like the "logp" method, but also take an explicit resource bundle name for use in localizing the log message.There are convenience methods for tracing method entries (the "entering" methods), method returns (the "exiting" methods) and throwing exceptions (the "throwing" methods).Finally, there are a set of convenience methods for use in the very simplest cases, when a developer simply wants to log a simple string at a given log level. These methods are named after the standard Level names ("severe", "warning", "info", etc.) and take a single argument, a message string.

For the methods that do not take an explicit source name and method name, the Logging framework will make a “best effort” to determine which class and method called into the logging method. However, it is important to realize that this automatically inferred information may only be approximate (or may even be quite wrong!). Virtual machines are allowed to do extensive optimizations when JITing and may entirely remove stack frames, making it impossible to reliably locate the calling class and method.

All methods on Logger are multi-thread safe.

Subclassing Information: Note that a LogManager class may provide its own implementation of named Loggers for any point in the namespace. Therefore, any subclasses of Logger (unless they are implemented in conjunction with a new LogManager class) should take care to obtain a Logger instance from the LogManager class and should delegate operations such as “isLoggable” and “log(LogRecord)” to that instance. Note that in order to intercept all logging output, subclasses need only override the log(LogRecord) method. All the other logging methods are implemented as calls on this log(LogRecord) method.

總結

以上是生活随笔為你收集整理的java.util.logging.Logger基础教程的全部內容，希望文章能夠幫你解決所遇到的問題。

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