Java Log4j、commons日志、JDK日志和SLF4J是如何相互关联的？

它们是彼此的替代、依赖、API还是实现？

---

为什么它们会存在呢？

通常你会看到它们是分层的

SLF4J纯粹是一个抽象层，其本身并不用于日志的实际输出，而是由您在代码中用于记录消息

典型的设置是使用SLF4J登录代码，然后使用适当的SLF4J->log4j桥（您只在类路径中包含的jar）将log4j用作底层“输出”层。为了合并来自不同来源的日志，存在各种桥接。例如，许多应用服务器（如tomcat）将使用JDK日志记录，以避免在部署的应用程序上强制使用“非标准”日志记录框架。为此，slf4j有一个桥接器，可以从JDK日志中获取所有输出。所以，这可能是一个堆栈

JDK-logging <- Your app-server or framworks might log using this
  |
(JDK->Slf4j bridge)
  |
Slf4j <- your application logs using Slf4j
  |
(Slf4j->log4j bridge)
  |
log4j <- log4j is just responsible for outputting to the appenders you configure (file, console etc)

JDK日志（Slf4j桥）
|
Slf4j log4j桥）
|
log4j我最近也在研究这个问题。我已经在Commons日志中使用Log4J多年了，最近切换到了SLF4J

Log4j是一个用于实际编写/分发日志的框架。它非常灵活：您可以引导它向文件、系统日志、远程监控等发送日志消息。您还可以配置多个记录器、日志类别、在条目中包含上下文等。这是最流行的记录系统之一

内置的JDK日志记录（老实说，我从未使用过）是在JDK1.4.2中添加的。据我所知，它不是很受欢迎，因为它不如Log4j灵活，但我欢迎评论：）

及
这两个都是各种日志框架之上的外观，这些框架为您的应用程序提供了一个通用接口。例如，您可以在应用程序中使用CL/SLF4J，它们将自动检测底层记录器实现（Log4J、JDK日志或只委托给
System.err.println（）
）的内置记录器）。这样做的好处是，您或您的最终用户可以决定随意切换底层日志记录实现，并且他们通过消除Log4J和JDK日志记录的许多复杂性，大大简化了您的实现
 SLF4J只是一个具有不同后端（任何其他日志系统）的通用API。Log4j和commons日志（CL）不同的日志库，CL是一个化石。但它们都是，所以sun发明了JDK日志记录

至于我，我更喜欢SLF4J，因为它最灵活，并且是它的后端。Logback是最现代的，有很多很好的特性。
啊，Java中的日志框架。您的问题混合了两种不同类型的库：


log4j和JDK日志记录是用于处理日志记录的库
Commons日志和SLF4J都是日志外观：您仍然需要一个真正的日志实现（比如log4j）

如果您正在编写一个将在其他人的系统中使用的库，那么您应该使用日志外观，因为您不知道他们将使用哪个日志框架。在本例中，使用SLF4J（Commons日志记录较旧，并且存在一些类加载器问题）

如果您控制整个应用程序，并且可以指定使用哪个日志框架，那么您可以自由选择自己的首选项。我的首选解决方案是（按优先顺序）：


倒退
log4j
JDK日志记录（在我看来，这是SUN“并非发明于此”的一个案例）
我对CL的看法是错误的，它也是API。有一个关于SLF4J优点的链接：JDK日志记录在应用服务器和框架中使用得比较普遍（因为它在jre中默认存在），以避免向其他日志记录框架添加容器级依赖项。这样，我们就可以决定在开发应用程序时使用什么日志堆栈。