我们可以用两种方式调用Log4j
1）在包的每个类中使用静态Logger引用并调用记录器
2）在一次“静态”类中有一个静态Logger引用，并从每个地方引用这个“静态”类
基于记忆哪种方法有效哪种方法一般好？
答案 0 :(得分：2)
第一种方法使您能够在每个类的基础上控制（例如设置级别）日志记录。这是以拥有大量Logger实例为代价的。
第二种方法为您提供了一个Logger实例，但只允许您控制 记录整个应用程序。
AFAIK，在长期运行的应用程序中，拥有大量（静态）Logger实例的唯一持续成本是内存使用量的小增量。因此，这是内存使用量的小幅增加与应用程序日志记录的灵活性/可配置性之间的权衡。
虽然我不会在每个班级中创建一个Logger，但我认为如果您在整个应用程序中只使用一个Logger，那么您（或您的用户/客户）可能会后悔。 / p>
答案 1 :(得分：0)
创建多个记录器将占用更多内存，因为用于Log4j的LoggerRepository需要维护另一个记录器。但是这个内存量应该是微不足道的，并且通过为每个类设置不同的记录器，您可以轻松地跟踪日志语句的来源。您还可以为不同的包/类打开不同的日志级别。我不建议让所有类使用一个记录器。
答案 2 :(得分：0)
显然，方法＃2的内存效率更高。但话说回来，这通常是一个坏主意。您将错过每个类/包日志过滤功能，这使得log4j非常有用。除非你的内存预算方法非常紧张，否则＃1确实是首选。
第三种方式是调用log4j，这更加耗费内存：在每个类中使用非静态成员。您可以使用以下内容：
protected Logger log = Logger.getLogger(getClass());
如果你的类将被子类化，那么这可能是更可取的，因为getClass（）总是引用实际的实例类。
答案 3 :(得分：0)
请记住，Log4j已知在某些情况下占用PermGen空间的问题，但通常不会出现单个应用程序实例的时间问题，这可能导致OutOfMemoryError异常。
在大多数情况下可以看到将应用程序部署到Java EE应用程序服务器时，在每次部署时，最后一次部署的静态记录器将保留在ClassLoader中。当您在不重新启动应用程序服务器的情况下多次重新部署应用程序时，这只是一个问题（我主要是在开发过程中整天重新部署应用程序时发生这种情况）。
通常，也许是非问题，但需要注意的事项。您可以通过搜索“log4j permgen”之类的内容找到有关它的更多信息。