分類、ログフレーム
- ファサード型ロギングフレームワーク：
- jakartaCommonsLoggingImpl（JCL）。
- Java用のシンプルなログファサード（SLF4J）。
- レコードタイプのロギングフレームワーク：
- 7月：JDKでのロギングツールは、しばしばJDKLog、JDK-ロギングを言及しました。
- Log4jの：特定の実装フレームワークをログに記録します。
- Log4j2：特定のログの実装フレームワークは、それがLOG4J1の次のバージョンです。
- Logback：具体的な実施体制、より良いパフォーマンスをログに記録します。
第二に、開発プロセス
彼らの関係を把握するために、我々は、彼らがどのような状況の下で生産されて起動する必要があります。私たちは、導入する年代順に従ってください。
Laog4j
JDK 1.3およびそれ以前では、Javaはログを打つ頼るのSystem.out.println（）、System.err.println（）またはe.printStackTrace（）、デバッグログはSTDOUTストリームに書き込まれ、エラーログはSTDERRストリームに書き込まれています。この戦いのログをカスタマイズすることができない非常に大きな欠陥があり、ログのサイズは十分に詳細ではありません。
だから、GülcüLog4jのは、2001年にリリースされ、後にApache Foundationのトップレベルのプロジェクトとなりました。デザインのlog4jは、非常に良いですが、現在広く使用されているなど、その定義などのJavaログ、ロガー、アペンダ、レベルの概念の次のフレームに長期的かつ遠大な影響があります。LogbackとLog4j2うち、使用してLog4jのも減少した後、Log4jのショートボードのパフォーマンス。
7月
Logjに触発され、Sunは、開発者が独自のアペンダ（Sunはハンドラと呼ばれる）、および利用可能な唯一の2つのハンドラ（コンソールを作成する必要がありますので、多くの完全なのjava.util.logging、log4jのが、7月のJava1.4のバージョンを導入し、ファイル）、Java1.5のパフォーマンスと可用性後の7月には、強化されています。
JCL（コモンズ-ログ）
少なくとも一つの枠組みの中でログプリント二つのプロジェクトの不可避な選択ので、この時点では、ApacheのJCL（コモンズ・ロギングは）生まれました。JCLがログファサードで、唯一のログAPIを提供し、そこアダプターLog4jのか、7月にはログの実装として使用され、実装を提供していません。
ログは、プログラムで作成され、記録されているのLog4jのLog4jを使用することがある場合ではない、その結果は、JDK 7月を使用する場合、実際の運転では、我々はCLASSPATHに現在あるものを見ていきますが、達成されるJCLのインタフェースを使用しています。
このように、あなたのプロジェクトだけでなく、サードパーティのプロジェクトでは、我々は、最終的にログの実装の適切な使用を選択するために、自分たちのニーズ（または好み）に応じて、プログラムを実行するときに、JCLロギング・インターフェースを使用しています。あなたはLog4jのを使用している場合は、Log4jのジャーパッケージが中に追加され、その後、Log4jの設定ファイルを作成し、7月には使用したい場合は、あなただけの設定ファイル7月を記述する必要があります。他の新しいログライブラリがある場合は表示され、それが唯一のアダプタを提供する必要があり、ログデータベースのjarパッケージを実行しているこの時間が追加されました。
しかし、コモンズ・ロギングとLog4jの構成の問題7月相性が良くない、コモンズ-loggingsもNoClassDefFoundErrorがエラーをリードし、クラスローディングの問題が発生することがあります。
この時点で、すべては非常に良い、非常にシンプルに見えます。インターフェイスと良好な分離を行うための実装では、統一されたJCLの下で、任意のコードを変更せずに、あなたはより強力な、より良いパフォーマンスへの切り替えやライブラリの実装をロギングすることで、それを構成することができます。
この単純な美しいSLF4Jが表示されるように続けました。
SLF4J＆Logback
SLF4J（Simple Logging Facade for Java）和 Logback 也是Gülcü 创立的项目，目的是为了提供更高性能的实现。
从设计模式的角度说，SLF4J 是用来在log和代码层之间起到门面作用，类似于 JCL 的 Log Facade。对于用户来说只要使用SLF4J提供的接口，即可隐藏日志的具体实现，SLF4J提供的核心API是一些接口和一个LoggerFactory的工厂类，用户只需按照它提供的统一纪录日志接口，最终日志的格式、纪录级别、输出方式等可通过具体日志系统的配置来实现，因此可以灵活的切换日志系统。
Logback是log4j的升级版，当前分为三个目标模块：
- logback-core：核心模块，是其它两个模块的基础模块
- logback-classic：是log4j的一个改良版本，同时完整实现 SLF4J API 使你可以很方便地更换成其它日记系统如log4j 或 JDK14 Logging
- logback-access：访问模块与Servlet容器集成提供通过Http来访问日记的功能，是logback不可或缺的组成部分
Logback相较于log4j有更多的优点：
- 更快的执行速度
- 更充分的测试
- logback-classic 非常自然的实现了SLF4J
- 使用XML配置文件或者Groovy
- 自动重新载入配置文件
- 优雅地从I/O错误中恢复
- 自动清除旧的日志归档文件
- 自动压缩归档日志文件
- 谨慎模式
- Lilith
- 配置文件中的条件处理
- 更丰富的过滤
更详细的解释参见官网：https://logback.qos.ch/reasonsToSwitch.html
到这里，你可能会问：Apache 已经有了个JCL，用来做各种Log lib统一的接口，如果 Gülcü 要搞一个更好的 Log 实现的话，直接写一个实现就好了，为啥还要搞一个和SLF4J呢?
原因是Gülcü 认为 JCL 的 API 设计得不好，容易让使用者写出性能有问题的代码。关于这点，你可以参考这篇文章获得更详细的介绍：https://zhuanlan.zhihu.com/p/24272450
现在事情就变复杂了。我们有了两个流行的 Log Facade，以及三个流行的 Log Implementation。Gülcü 是个追求完美的人，他决定让这些Log之间都能够方便的互相替换，所以做了各种 Adapter 和 Bridge 来连接:
可以看到甚至 Log4j 和 JUL 都可以桥接到SLF4J，再通过 SLF4J 适配到到 Logback！需要注意的是不能有循环的桥接，比如下面这些依赖就不能同时存在:
- jcl-over-slf4j 和 slf4j-jcl
- log4j-over-slf4j 和 slf4j-log4j12
- jul-to-slf4j 和 slf4j-jdk14
然而，事情在变得更麻烦！
Log4j2
现在有了更好的 SLF4J 和 Logback，慢慢取代JCL 和 Log4j ，事情到这里总该大统一圆满结束了吧。然而维护 Log4j 的人不这样想，他们不想坐视用户一点点被 SLF4J / Logback 蚕食，继而搞出了 Log4j2。
Log4j2 和 Log4j1.x 并不兼容，设计上很大程度上模仿了 SLF4J/Logback，性能上也获得了很大的提升。Log4j2 也做了 Facade/Implementation 分离的设计，分成了 log4j-api 和 log4j-core。
现在好了，我们有了三个流行的Log 接口和四个流行的Log实现，如果画出桥接关系的图来回事什么样子呢?
看到这里是不是感觉有点晕呢？是的，我也有这种感觉。同样，在添加依赖的时候，要小心不要有循环依赖。