近期，考虑到Job系统需要打很多的日志（调用别人的API真的是坑呀，一不留神别人就把你限流了，还是别人内部服务器的问题，所以还是要多打印些日志）。笔者想优化下日志系统，然后成功又把自己拐坑里了。不过也是因为自己对于日志系统不够充分了解，借此机会更好的了解日志系统。
优化的手段比较简单：
- 生产环境去除打印控制台日志
- 将RollingFile改为RollingRandomAccessFile
- 添加Disruptor的Jar，开启Log4j2的异步化
ps：优化2是借用RollingRandomAccessFile中的buffer来提升IO效率，在开启Log4j2的异步化之后，笔者选择将RollingRandomAccessFile改回RollingFile。另外，异步化也不是十全十美的，在停止服务的时候会损失一部分日志的。如果能在停止服务的时候Sleep一段时间那是最好的，本项目对于一部分日志不在意所以也就没加Sleep。
步骤1：剔除Log4j1
既然需要用到Log4J2，那么就需要将所有的Log4j1的Jar给剔除。
mvn dependency:tree --> tree.txt
[INFO] | +- org.apache.hadoop:hadoop-hdfs:jar:2.5.1:compile
[INFO] | | +- log4j:log4j:jar:1.2.17:compile
把依赖树打印出来，发现hdfs的Jar下有Log41，找准Log4j1，使用：
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
结果发现没有生效……哔了狗了。这个Jar是包含在Biz层的pom中，索性我直接把Biz的Log4j1给剔除了。
世界应该安静了吧，结果报错了。
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Level
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 66 more
不应该呀网上都说日志系统都是使用common-log或者slf4j，除非是直接使用Log41的代码~ 看代码hdfs也是用的common-log呀。查了两天发现hdfs使用了hdfs的INFO级别的常量…………所以，Log4j1不能删除，坑爹呀。
步骤2：隔离Log4j1
行吧，既然Hdfs你是大爷，你要用就用呗。但是打印日志如何嫁接到Log4j2上面，这个就是我要做的工作了。万能的google告诉我添加jcl-over-slf4j的Jar就可以解决问题，jcl-over-slf4j能够将commom-log嫁接到slf4j上，然后添加log4j-slf4j-impl:jar:2.7的Jar就能使用Log4j2。
这就陷入了我的知识盲区，为何添加Jar就能成功切换日志系统？
解决方案：万事不懂先google看别人原理讲解，然后在自己乖乖看源码。
Commom-log原理
commom-log：
- 从System.properties中查找LogFactory
- 从SPI来找
- 使用默认的LogFactoryImpl
为了方便大家理解，笔者把代码给抠了出来，还把常量给替换了方便看，可自行在common-log 1.2中搜索找到。
第一步，从System.properties中查找LogFactory
String factoryClass = getSystemProperty("org.apache.commons.logging.LogFactory", null);
factory = newFactory(factoryClass, baseClassLoader, contextClassLoader);
第二步，从SPI来找
final InputStream is = getResourceAsStream(contextClassLoader, "META-INF/services/org.apache.commons.logging.LogFactory");
...
...
factory = newFactory(factoryClassName, baseClassLoader, contextClassLoader );
public InputStream getResourceAsStream(String name) {
URL url = getResource(name);
try {
return url != null ? url.openStream() : null;
} catch (IOException e) {
return null;
}
}
ps:使用Java 1.6提供的java.util.ServiceLoader也是不错的选择，dubbo即其他很多框架都是SPI的最好实践者。
第三步，使用默认的LogFactoryImpl
factory = newFactory("org.apache.commons.logging.impl.LogFactoryImpl", thisClassLoader, contextClassLoader);
以下是每个会去寻找的Logger：
private static final String[] classesToDiscover = {
LOGGING_IMPL_LOG4J_LOGGER,
"org.apache.commons.logging.impl.Jdk14Logger",
"org.apache.commons.logging.impl.Jdk13LumberjackLogger",
"org.apache.commons.logging.impl.SimpleLog"
};
Slf4j原理
从classPath中查找，将StaticLoggerBinder绑定到 Enumeration paths 上。
ClassLoader loggerFactoryClassLoader = LoggerFactory.class.getClassLoader();
Enumeration<URL> paths;
if (loggerFactoryClassLoader == null) {
paths = ClassLoader.getSystemResources("org/slf4j/impl/StaticLoggerBinder.class");
} else {
paths = loggerFactoryClassLoader.getResources("org/slf4j/impl/StaticLoggerBinder.class");
}
while (paths.hasMoreElements()) {
URL path = paths.nextElement();
staticLoggerBinderPathSet.add(path);
}
可以看到log4j-slf4j-impl:jar:2.7中就有StaticLoggerBinder.class这个类。
总结
可以看到Commom-log和Slf4j为我们提供了两种做插件化服务很好的思路。Common-log使用接口（SPI的模式）或者是Slf4j使用门面模式（StaticLoggerBinder.class）来实现插件化，都是不错的选择。
最后，推荐一波Log4j2的异步化。
性能测试可看：
