java程序正确的打印日志

什么是日志

简单的说,日志就是记录程序的运行轨迹,方便查找关键信息,也方便快速定位解决问题。

我们 Java 程序员在开发项目时都是依赖 Eclipse/ Idea 等开发工具的 Debug 调试功能来跟踪解决 Bug,在开发环境可以这么做,但项目发布到了测试、生产环境呢?你有可能会说可以使用远程调试,但实际并不能允许让你这么做。

所以,日志的作用就是在测试、生产环境没有 Debug 调试工具时开发、测试人员定位问题的手段。日志打得好,就能根据日志的轨迹快速定位并解决线上问题,反之,日志输出不好不能定位到问题不说反而会影响系统的性能。

优秀的项目都是能根据日志定位问题的,而不是在线调试,或者半天找不到有用的日志而抓狂…

常用日志框架

log4j、Logging、commons-logging、slf4j、logback,开发的同学对这几个日志相关的技术不陌生吧,为什么有这么多日志技术,它们都是什么区别和联系呢?相信大多数人搞不清楚它们的关系,下面我将一一介绍一下,以后大家再也不用傻傻分不清楚了。

Logging
这是 Java 自带的日志工具类,在 JDK 1.5 开始就已经有了,在 java.util.logging 包下。

Log4j
Log4j 是 Apache 的一个开源日志框架,也是市场占有率最多的一个框架。大多数没用过 Java Logging, 但没人敢说没用过 Log4j 吧,反正从我接触 Java 开始就是这种情况,做 Java 项目必有 Log4j 日志框架。

注意:log4j 在 2015/08/05 这一天被 Apache 宣布停止维护了,用户需要切换到 Log4j2上面去。

commons-logging
上面介绍的 log4j 是一个具体的日志框架的实现,而 commons-logging 就是日志的门面接口,它也是 apache 最早提供的日志门面接口,用户可以根据喜好选择不同的日志实现框架,而不必改动日志定义,这就是日志门面的好处,符合面对接口抽象编程。

Slf4j
全称:Simple Logging Facade for Java,即简单日志门面接口,和 Apache 的 commons-logging 是一样的概念,它们都不是具体的日志框架,你可以指定其他主流的日志实现框架。

Slf4j 也是现在主流的日志门面框架,使用 Slf4j 可以很灵活的使用占位符进行参数占位,简化代码,拥有更好的可读性,这个后面会讲到。

Logback
Logback 是 Slf4j 的原生实现框架,同样也是出自 Log4j 一个人之手,但拥有比 log4j 更多的优点、特性和更做强的性能,现在基本都用来代替 log4j 成为主流。

为什么 Logback 会成为主流?

无论从设计上还是实现上,Logback相对log4j而言有了相对多的改进。不过尽管难以一一细数,这里还是列举部分理由为什么选择logback而不是log4j。牢记logback与log4j在概念上面是很相似的,它们都是有同一群开发者建立。所以如果你已经对log4j很熟悉,你也可以很快上手logback。如果你喜欢使用log4j,你也许会迷上使用logback。

更快的执行速度

基于我们先前在log4j上的工作,logback 重写了内部的实现,在某些特定的场景上面,甚至可以比之前的速度快上10倍。在保证logback的组件更加快速的同时,同时所需的内存更加少。

更多请参考《从Log4j迁移到LogBack的理由 》

日志框架总结
commons-loggin、slf4j 只是一种日志抽象门面,不是具体的日志框架。
log4j、logback 是具体的日志实现框架。
一般首选强烈推荐使用 slf4j + logback。当然也可以使用slf4j + log4j、commons-logging + log4j 这两种日志组合框架。

日志级别详解

项目中最常用有日志级别是ERROR、WARN、INFO、DEBUG四种了,这四个都有怎样的应用场景呢。

ERROR(错误)
一般用来记录程序中发生的任何异常错误信息(Throwable),或者是记录业务逻辑出错。

WARN(警告)
一般用来记录一些用户输入参数错误、

INFO(信息)
这个也是平时用的最低的,也是默认的日志级别,用来记录程序运行中的一些有用的信息。如程序运行开始、结束、耗时、重要参数等信息,需要注意有选择性的有意义的输出,到时候自己找问题看一堆日志却找不到关键日志就没意义了。

DEBUG(调试)
这个级别一般记录一些运行中的中间参数信息,只允许在开发环境开启,选择性在测试环境开启。

几个错误的打日志方式

1. 不要使用 System.out.print..
输出日志的时候只能通过日志框架来输出日志,而不能使用 System.out.print.. 来打印日志,这个只会打印到 tomcat 控制台,而不会记录到日志文件中,不方便管理日志,如果通过服务形式启动把日志丢弃了那更是找不到日志了。

2. 不要使用 e.printStackTrace()
首先来看看它的源码:

public void printStackTrace() {
printStackTrace(System.err);
}

它其实也是利用 System.err 输出到了 tomcat 控制台。

3. 不要抛出异常后又输出日志
如捕获异常后又抛出了自定义业务异常,此时无需记录错误日志,由最终捕获方进行异常处理。不能又抛出异常,又打印错误日志,不然会造成重复输出日志。

try {
// ...
} catch (Exception e) {
// 错误
LOG.error("xxx", e);
throw new RuntimeException();
}

4. 不要使用具体的日志实现类
InterfaceImpl interface = new InterfaceImpl();

这段代码大家都看得懂吧?应该面向接口的对象编程,而不是面向实现,这也是软件设计模式的原则,正确的做法应该是。

Interface interface = new InterfaceImpl();

日志框架里面也是如此,上面也说了,日志有门面接口,有具体实现的实现框架,所以大家不要面向实现编程。

5. 没有输出全部错误信息
看以下代码,这样不会记录详细的堆栈异常信息,只会记录错误基本描述信息,不利于排查问题。

try {
// ...
} catch (Exception e) {
// 错误
LOG.error('XX 发生异常', e.getMessage());

// 正确
LOG.error('XX 发生异常', e);
}

6. 不要使用错误的日志级别
try {
// ...
} catch (Exception e) {
// 错误
LOG.info("XX 发生异常...", e);
}

大家看出了什么问题吗?用 info 记录 error 日志,日志输出到了 info 日志文件中了,同事拼命地在 error 错误日志文件里面找怎么能找到呢?

7. 不要在千层循环中打印日志
这个是什么意思,如果你的框架使用了性能不高的 Log4j 框架,那就不要在上千个 for循环中打印日志,这样可能会拖垮你的应用程序,如果你的程序响应时间变慢,那要考虑是不是日志打印的过多了。

for(int i=0; i<2000; i++){
LOG.info("XX");
}

最好的办法是在循环中记录要点,在循环外面总结打印出来。

8. 禁止在线上环境开启 debug
这是最后一点,也是最重要的一点。

一是因为项目本身 debug 日志太多,二是各种框架中也大量使用 debug 的日志,线上开启 debug 不久就会打满磁盘,影响业务系统的正常运行。

你可能感兴趣的:(java,log4j,apache)