为什么不建议每次都调用LoggerFactory.getLogger（...）？ [英] Why calling LoggerFactory.getLogger(...) every time is not recommended?

问题描述

我已经阅读了大量帖子和文档（在此网站和其他地方），指出SFL4J日志记录的推荐模式是：

I've read tons of posts and documents (on this site and elsewhere) pointing that the recommended pattern for SFL4J logging is:

public class MyClass {
    final static Logger logger = LoggerFactory.getLogger(MyClass.class);

    public void myMethod() {
        //do some stuff
        logger.debug("blah blah blah");
    }
}

我的老板更喜欢我们只使用包装来截取日志调用并避免锅炉板代码在每个类上声明记录器：

My boss prefers we just use a wrapper to intercept log calls and avoid boiler plate code for declaring the logger on every class:

public class MyLoggerWrapper {
    public static void debug(Class clazz, String msg){
        LoggerFactory.getLogger(clazz).debug(msg));
    }
}

并简单地使用它：

public class MyClass {

    public void myMethod() {
        //do some stuff
        MyLoggerWrapper.debug(this.getClass(), "blah blah blah");
    }
}

我假设每次登录时都会实例化一个记录器昂贵，但我一直无法找到支持这一假设的任何文件。除此之外他肯定说框架（LogBack或Log4J我们仍在决定）会缓存记录器，而且无论如何服务器的运行速度都远远低于它们的容量，所以这不是问题。

I presume instantiating a logger every time we log is somewhat expensive but I've been unable to find any document backing that assumption. Besides he says surely the framework (LogBack or Log4J we're still deciding) will "cache" the loggers and also that in any case the servers are running very much below their capacity so it is not an issue.

有任何帮助指出这种方法的潜在问题吗？

Any help pointing out potential problems with this approach?

推荐答案

这是一个明显的问题这种方法：每次调用 debug（）时都会构造String消息，没有明显的方法可以在包装器中使用guard子句。

Here is one obvious problem with this approach: the String messages will be constructed on each call to debug(), there is no obvious way to use a guard clause with your wrapper.

log4j / commons-logging / slf4j的标准习惯是使用一个保护条款，例如：

The standard idiom with log4j/commons-logging/slf4j is to use a guard clause such as:

if (log.isDebugEnabled()) log.debug("blah blah blah");

目的是如果 DEBUG 对于记录器没有启用级别，编译器可以避免将您可能发送的任何更长的字符串连接在一起：

With the purpose being that if the DEBUG level is not enabled for the logger, the compiler can avoid concatenating together any longer strings you may send it:

if (log.isDebugEnabled()) log.debug("the result of method foo is " + bar 
     + ", and the length is " + blah.length());

参见（不）记录的最快方法是什么？在SLF4J 或 log4j 常见问题解答。

我建议反对老板建议的包装。像slf4j或commons-logging这样的库已经是围绕所使用的实际底层日志记录实现的一个外观。此外，每次调用记录器都会变得更长 - 比较上面的

I would recommend against the "wrapper" your boss suggests. A library like slf4j or commons-logging is already a facade around the actual underlying logging implementation used. In addition, each invocation of the logger becomes much lengthier - compare the above with

 MyLoggerWrapper.debug(Foo.class, "some message");

这是一种琐碎而不重要的包装和混淆，除了添加之外没有任何其他用途间接层和丑陋的代码层。我认为你的老板可以找到更重要的问题来讨论。

This is the type of trivial and unimportant "wrapping" and obfuscation that serves no real purpose other than adding layers of indirection and ugly-fying your code. I think your boss can find more important issues to obsess over.

这篇关于为什么不建议每次都调用LoggerFactory.getLogger（...）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！