Java gc日志 时间单位 java的日志是什么

前言

最近和一个大神聊了写Java记录日志的相关知识，觉得很有用，写出来记录一下。本篇博客涉及到Log4J，JCL，JUL，SLF4J等相关知识。同时也会介绍一下JCL的源码是怎么去循环调用不同的LOG实现的。更多Spring内容进入【Spring解读系列目录】。

JUL（java.util.logging.Logger）

此为Java自带的一个日志记录的技术，能够直接实现Log的输出，直接用就可以。

public class JUL {
    public static void main(String[] args) {
        Logger logger=Logger.getLogger("jul");
        logger.info("JUL");
    }
}

Log4J（org.apache.log4j.Logger）

相信这位是大家的老朋友了。用的非常广泛，也能够直接实现Log的输出，但是要引入依赖。

<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.12</version>
</dependency>

public class Log4j {
    public static void main(String[] args) {
        Logger logger=Logger.getLogger("log4j");
        logger.info("log4j");
    }
}

JCL（org.apache.commons.logging.Log）

JCL其实算是一个抽象的Log接口，它自己本身不能够打印日志，必须通过第三方打印，而且也要引入依赖才可以。但是JCL目前官方已经不再更新了，因此JCL也是逐渐被SLF4J所代替，但是Spring4中依然在其Core包中使用，可见其代码还是非常厉害的，不过这是后话了，因为Spring5就不用了。

<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>1.2</version>
</dependency>

如果我们不进行任何的依赖，下面的代码会直接使用JUL的技术打印出来。但是一旦引入了Log4J，JCL就会抛弃JUL转去使用Log4J为什么会这样呢？我们下面就去JCL的源码里扒一扒原因是什么。

public class JCL {
    public static void main(String[] args) {
        Log log= LogFactory.getLog("jcl");
        log.info("jcl");
    }
}
JUL打印结果：
Sep 21, 2020 3:51:21 PM com.demo.main.JCL main
INFO: jcl

引入Log4J依赖以后打印结果：
2020-09-21 15:50:53,887 INFO [jcl] - jcl

JCL的选择

从main方法里的代码看JCL是使用一个工厂调出来一个Log实例来使用的，所以我们需要去找的就是谁产生了Log类的实例，点击进去getLog()方法：

public static Log getLog(String name) throws LogConfigurationException {
    return getFactory().getInstance(name);
}

找到了一个一眼就能看出来的方法getInstance(name)，这个方法是一个接口，但是只有一个实现方法，所以就直接到了LogFactoryImpl. getInstance()方法

public Log getInstance(String name) throws LogConfigurationException {
	//如果get不到
    Log instance = (Log)this.instances.get(name);
    if (instance == null) {
	//new 一个新的
        instance = this.newInstance(name);
        this.instances.put(name, instance);
    }
    return instance;
}

在一开始Log4J和JUL都不确定的情况下一定是不是get出来的，通过调试确实也是如此，直接就进入this.newInstance(name);就可以了。

protected Log newInstance(String name) throws LogConfigurationException {
    try {
        Log instance;
        Object[] params;
        if (this.logConstructor == null) {
            instance = this.discoverLogImplementation(name);
        } else {
            params = new Object[]{name};
            instance = (Log)this.logConstructor.newInstance(params);
        }
        if (this.logMethod != null) {
            params = new Object[]{this};
            this.logMethod.invoke(instance, params);
        }
        return instance;
    }
	......
}

进入后发现这个方法最终返回了instance，所以就要找到哪里产生了这个instance，可以看到只有instance = this.discoverLogImplementation(name)被第一次生成了。

private Log discoverLogImplementation(String logCategory) throws LogConfigurationException {
	......
    Log result = null;
    if (specifiedLogClassName != null) {
	......
} else {
        if (isDiagnosticsEnabled()) {
            this.logDiagnostic("No user-specified Log implementation; performing discovery using the standard supported logging implementations...");
        }
        for(int i = 0; i < classesToDiscover.length && result == null; ++i) {
            result = this.createLogFromClass(classesToDiscover[i], logCategory, true);
        }
        if (result == null) {
            throw new LogConfigurationException("No suitable Log implementation");
        } else {
            return result;
        }
    }
}

首先先去找到返回，发现返回的是result，往上找到谁给了result的值。这里笔者通过调试得知的最重要的就是最后的这个for循环。

for(int i = 0; i < classesToDiscover.length && result == null; ++i) {
    result = this.createLogFromClass(classesToDiscover[i], logCategory, true);
}

这个for循环里循环的是classesToDiscover这个数组，而这个数组里面存的内容就是JCL选择实现器的优先级，看看里面存了什么。

private static final String[] classesToDiscover = new String[]
{"org.apache.commons.logging.impl.Log4JLogger", 
"org.apache.commons.logging.impl.Jdk14Logger", 
"org.apache.commons.logging.impl.Jdk13LumberjackLogger", 
"org.apache.commons.logging.impl.SimpleLog"};

是不是很震惊，居然这么low，就是写死的类名。因为这里是for循环，第一个必然就是读到了Log4JLogger。如果没有读到，就找下一个Jdk14Logger。再读不到接着走下一个。当然这里其实读取到Jdk14Logger就已经停了，后面是不会用了，因为现在谁还用比Java 4版本还低的开发东西？为了验证我们的说法，进入createLogFromClass方法看一眼，方法很长我们就说重点，这里略去了很多不相干的代码。

private Log createLogFromClass(String logAdapterClassName, String logCategory, boolean affectState) throws LogConfigurationException {
    Log logAdapter = null;//返回值
    Constructor constructor = null;
    while(true) {
        String resourceName;
        try {
            ...
            Class c; //创建类对象
            try {
            	//反射拿到对象，这个名字就是外面数组里的四个类名
                c = Class.forName(logAdapterClassName, true, currentCL); 
            } catch (ClassNotFoundException var15) {
            	 ......
                 break; //如果没有拿到，跳出循环while(true)
            }
            //反射拿到构造方法
            constructor = c.getConstructor(this.logConstructorSignature);
            //反射利用构造方法拿到对象
            Object o = constructor.newInstance(params);
            if (o instanceof Log) {
                logAdapterClass = c;
                logAdapter = (Log)o; //赋值
                break;
            }
            this.handleFlawedHierarchy(currentCL, c);
        } 
    }//返回出去
    return logAdapter;
}

可以看到这里如果没有通过Class.forName拿到class对象，直接捕获异常，就跳出了while循环，然后返回一个null出去。而外面的for循环因为满足classesToDiscover.length && result == null条件会继续下次循环。也就是说Log4JLogger没找到就用Jdk14Logger作为保底的。简言之，JCL底层通过预先存放了具体的日志框架类名的一个数组，去循环匹配这些类名是否在项目中被依赖了，如果找到依赖的则直接使用，因而使用上也有先后顺序的分别。

SLF4J（Simple Logging Facade for Java）

之前说过JCL官方已经不更新了，反而是SLF4J越来越广泛。那么我们就对比一下这俩的处理流程是有什么区别。

看起来差别不大，但是slf4j每次只能绑定一个，也就是它的binder只能依赖一个，绑定谁用谁。由于其扩展性很强所以用的人自然也越来越多。网上关于SLF4J的例子到处都是，详解这里就不说了，说一些大家比较容易忽略或者出错的地方。

SLF4J的简单使用

首先当然还是要搬出来官网：

Note that SLF4J-enabling your library implies the addition of only a single mandatory dependency, namely slf4j-api.jar. If no binding is found on the class path, then SLF4J will default to a no-operation implementation.

要想使用SLF4J必须要有的(mandatory)依赖就是slf4j-api.jar，其次如果没有发现binding那就什么也不会去做(no-operation implementation)。其实没有绑定任何实现的话，控制台是会输出提示的，想必大家都见过：

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

不得不说SLF4J的这个提示还是很贴心的，怎么解决哪个网站都给贴上了。比如我们要用Log4J作为log输出，就直接引入下面两个依赖就可以了。

//<!--slf4j api-->
<dependency> 
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <version>1.7.30</version>
</dependency>
//<!--slf4j log4j绑定器-->
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>1.7.30</version>
</dependency>

public class SLF4J {
    public static void main(String[] args) {
        Logger logger= LoggerFactory.getLogger("slf4j");
        logger.info("slf4j");
    }
}
2020-09-21 17:11:29,309 INFO [slf4j] - slf4j

如果想要切换成JUL也十分简单，注释掉Log4J的依赖，添加新的JUL依赖就可以了：

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-jdk14</artifactId>
  <version>1.7.30</version>
</dependency>

Sep 21, 2020 5:09:06 PM com.demo.main.SLF4J main
INFO: slf4j

SLF4J的桥接器（Bridging）

SLF4J的桥接器是一个很厉害的地方，比如我们自己有一个A项目使用的是JUL的log，因为某些原因我们要引入另外一个B项目，但是这个B项目用的是Log4J做的日志。这两个项目日志打的不一致，收集起来就会很困难，如果有个项目C使用了Logback，那就又多了一种风格，很不好管理。这个时候SLF4J的桥接器就给我们提供了一个新的思路。而且操作起来非常简单，只需要给项目添加一个依赖就好了。

想使用Log4j就使用log4j-over-slf4j桥接过去，需要使用JUL就使用jul-to-slf4j bridge桥接过去。直接把依赖加上去就ok了。注意这里也只能添加一个，桥接也是多选一。

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>jcl-over-slf4j</artifactId>
  <version>1.7.30</version>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>log4j-over-slf4j</artifactId>
  <version>1.7.30</version>
</dependency>

比如说下面的例子，项目B使用的是Log4J作为日志输出。

<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.12</version>
</dependency>
<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>1.2</version>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <version>1.7.30</version>
</dependency>
public class SpringLog {
    public static void main(String[] args) {
        Log log = LogFactory.getLog("SpringLog");
        log.info("Spring");
        }
}
打印输出
2020-09-21 17:55:12,250 INFO [SpringLog] - Spring

为了让这个项目的日志输出桥接到JUL上，我们添加上下面的依赖再运行，就使得项目B的输出也变成了JUL的输出格式。

<!--jcl桥接器-->
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>jcl-over-slf4j</artifactId>
  <version>1.7.30</version>
</dependency>

<!--jul绑定器-->
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-jdk14</artifactId>
  <version>1.7.30</version>
</dependency>
打印输出
Sep 21, 2020 6:00:11 PM com.demo.main.SpringLog main
INFO: Spring

但是虽然很方便，但是注意的是这里不能桥接相同类型的日志。也就是说桥接器和绑定器器不能够一样，因为如果一样的话就会导致下面的情况，构成一个死循环，进而内存溢出。

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>jcl-over-slf4j</artifactId>
  <version>1.7.30</version>
</dependency>                   <!—错误示例-->
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-jcl</artifactId>
  <version>1.7.30</version>
</dependency>
输出错误
SLF4J: Detected both log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on the class path, preempting StackOverflowError. 
SLF4J: See also http://www.slf4j.org/codes.html#log4jDelegationLoop for more details.
Exception in thread "main" java.lang.ExceptionInInitializerError
	at org.slf4j.impl.StaticLoggerBinder.<init>(StaticLoggerBinder.java:72)
	at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:45)
	at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
	at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
	at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:417)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:362)
	at com.demo.main.SLF4J.main(SLF4J.java:8)
Caused by: java.lang.IllegalStateException: Detected both log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on the class path, preempting StackOverflowError. See also http://www.slf4j.org/codes.html#log4jDelegationLoop for more details.
	at org.slf4j.impl.Log4jLoggerFactory.<clinit>(Log4jLoggerFactory.java:54)
	... 7 more