打印 Logger 日志时,需不需要再封装一下工具类?

1,270 阅读3分钟

在开发过程中,打印日志是必不可少的,因为日志关乎于应用的问题排查、应用监控等。现在打印日志一般都是使用 slf4j,因为使用日志门面,有助于打印方式统一,即使后面更换日志框架,也非常方便。在 《Java 开发手册》中也有相关的规约。

所以在开发中,一般使用下面这种方式来打印日志。

LOGGER.info("print: {}", "this is the log");

不过有的应用会将 LOGGER 再封装一下,最终写成:

LoggerUtil.info(LOGGER, "print: {}", "this is the log");

本文的主要内容是讨论为什么要封装,有没有必要封装,以及怎样封装,如果小伙伴有更好的建议,可以提出,进行互相学习。

为什么要封装

很多人觉得 slf4j 本来就是日志门面,已经封装的很好了,为什么要多此一举,再额外封装一个 LoggerUtil 呢?

其实这块也是在开发规范中有说明的:

如果不进行封装,则会写成下面这种:

if (LOGGER.isInfoEnabled()) {
    LOGGER.info("print: {}", "this is the log");
}

所以,一般封装是将 if 判断这块逻辑统一封装为一个工具类。

可能到这里还有小伙伴不是很理解为什么要加 if 判断,可以看下下面这段代码:

可以看出转换逻辑这块相对比较复杂、耗时,在这里只是模拟的场景,实际使用可能会有其他情况,比如打印方法的出参入参、计算耗时等:

LOGGER.info("xxx 方法请求参数为:{}", JSON.toJSONString(req));
LOGGER.info("xxx 执行耗时:{}ms", System.currentTimeMillis() - startTime);

在某些场景下为了提高性能,需要关闭日志,比如大促,秒杀等等。

说到这里相信小伙伴已经看出问题了,因为这样写的话,当我关闭日志打印时,只是关闭了磁盘输出,但是耗时逻辑依然会继续执行。

# 日志级别调整到 error
logging.level.com.liuzhihang=error

这也是为什么在开发规范中建议大家手写判断,虽然日志框架中帮我们进行了判断,那只是避免了打印输出日志,实际上像组装日志,序列化实例对象等等还是会被执行的。

logback 框架中的判断逻辑

当然如果当前应用只有个位数的 tps 或者 tpm 那完全没必要考虑这些,也没必要因噎废食,正常使用就行。

该怎样封装

为了避免每次都要 if 判断的问题,会将 if 模块封装为工具类:

上面的封装,有效避免了每次都需要进行判断,只需要将代码中的打印日志换成 LogUtil 即可:

但是这种情况只能避免打印既有参数时的 if 判断,对方法类型的没有作用,这里就需要使用 Supplier

实际使用效果:

以上仅为一种封装方式,其他的封装可以自行考虑,比如整个日志框架都封装。

其他使用

这部分封装在 log4j-api-2.17.2.jar 中也有所体现,只不过 slf4j 里面并没有封装 Supplier 支持,详细实现可以自行阅读源码。

那为什么 slf4j 不支持,其实也是有讨论的,可以看 issue #70,里面进行了一系列讨论。

最终结果是在 2.0 支持了 Fluent Logging API 语法。

slf4j 2.0 使用

<!-- slf4j 2.0 依赖 -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>2.0.1</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>2.0.0</version>
</dependency>

按照官方文档的使用案例直接使用即可:

logger.atDebug()
    .setMessage("Temperature set to {}. Old value was {}.")
    .addArgument(() -> t16()).addArgument(oldT)
    .log();

为什么要这样写,只能说是人家的 API 设计就是如此,当然也有其他的考虑,可以看看 github issue。具体使用哪种,用不用封装等等,这些都是根据自己的实际情况来使用。

本文由mdnice多平台发布