Laog4j
ApacheのLog4jのオープンソースプロジェクトで、春Boot1.4およびそれ以降のバージョンは、もはやのlog4jをサポートして、log4jのは、長い間更新されていないされていない、今そこにある他の多くのlog4jロギングフレームワークは例SLF4J、Logbackなどのために、改善されました。
Log4j2
そしてLog4jの2とLogbackは、あらゆる点で非常に類似しているので、なぜ我々はLog4jの2が必要なのか
1.プラグ型構造。Log4jの2は、プラグイン構造をサポートしています。私たちは、私たちは、彼らのニーズに応じて独自のアペンダ、ロガー、フィルタを実装することができ、自分のLog4jの2に拡張することができます。
2.プロファイルの最適化。プロパティは、構成ファイル内で参照することができ、または代替的に直接コンポーネントに渡されてもよいです。そして、プロファイルJSON形式をサポートしています。他のロギングフレームワークとは異なり、ファイルは以前に失われていないログを再構成するための時間です。
3. Java 5の並行処理。Java 5のサポート、可能な限り最小レベルのロッキングの実装に並行処理機能を使用してlog4jの2。log4jの1.xで残された課題のデッドロックを解決するために、
4.非同期ロガー。Log4jの2は、LMAXかく乱ライブラリに基づいています。マルチスレッドのシナリオでは、既存のロギングフレームワークに比べて、非同期ロガーは、約10倍の効率向上があります。
公式には、いくつかの演算子が同期にログインし、非同期モードにログイン表示するには、平均的なプログラマを示唆しました。非同期ログ出力の利点は、印刷ログの機能を実行するために別のプロセスを使用することで、効率を向上させることができるログには、通常の業務上のログの影響を低減します。
クラスパスのプログラムで非同期ログは、破砕機-3.0.0.jarまたはそれ以上のバージョンをロードする必要があります。
<dependency>
<groupId>com.lmax</groupId> <artifactId>disruptor</artifactId> <version>3.3.6</version> </dependency>
非同期ログは二つのタイプに分けられます。
。完全な非同期モード
この非同期ログモードでは、設定ファイルを変更する原理を変更せずに、Loggerはまだ使用<root> して <logger>
のみ、メインプログラムの先頭でコードを必要とする、システムプロパティのコードを追加します。
System.setProperty("Log4jContextSelector", "org.apache.logging.log4j.core.async.AsyncLoggerContextSelector");
B非非同期および非同期モードミキシング出力
コンフィギュレーション・ファイルロガーの使用において<asyncRoot> または <asyncLogger>
<loggers> <AsyncLogger name="AsyncLogger" level="trace" includeLocation="true"> <appender-ref ref="Console" /> <appender-ref ref="debugLog" /> <appender-ref ref="errorLog" /> </AsyncLogger> <asyncRoot level="trace" includeLocation="true"> <appender-ref ref="Console" /> </asyncRoot> </loggers>
頼るlog4j2導入
春ブートプロジェクトを作成するとき、我々は春・ブート・スターター・ログが含まれている春ブート・スターターを導入し、コンテンツは、春ブーツデフォルトのロギングフレームワークLogbackに依存しています
我々はlog4j2を導入しましたので前に、私たちは、このパッケージに依存して除外し、その後log4j2の導入に依存する必要があります。
log4j2.xml構成
もう一つ注意すべきは、あなたがapplication.propertiesパスに保存されたログファイルを指定するか、ファイル名をログにlog4j2.xmlを使用する場合ということです${LOG_PATH}か${LOG_FILE}（参照、取得することはできませんlogbackにふけることができます）を使用します。
log4j2サポートXML、JSON、YAMLや他のコンフィギュレーション・ファイル・フォーマット。
SLF4J
SLF4J，即简单日志门面（Simple Logging Facade for Java），不是具体的日志解决方案，而是通过Facade Pattern提供一些Java logging API，它只服务于各种各样的日志系统。
按照官方的说法，SLF4J是一个用于日志系统的简单Facade，允许最终用户在部署其应用时使用其所希望的日志系统。作者创建SLF4J的目的是为了替代Jakarta Commons-Logging。
实际上，SLF4J所提供的核心API是一些接口以及一个LoggerFactory的工厂类。在使用SLF4J的时候，不需要在代码中或配置文件中指定你打算使用那个具体的日志系统。
类似于Apache Common-Logging，SLF4J是对不同日志框架提供的一个门面封装，可以在部署的时候不修改任何配置即可接入一种日志实现方案。
但是，他在编译时静态绑定真正的Log库。使用SLF4J时，如果你需要使用某一种日志实现，那么你必须选择正确的SLF4J的jar包的集合（各种桥接包）。
SLF4J提供了统一的记录日志的接口，只要按照其提供的方法记录即可，最终日志的格式、记录级别、输出方式等通过具体日志系统的配置来实现，因此可以在应用中灵活切换日志系统。
だから、より良いSLF4Jを使用しているとき？
あなたはライブラリまたは埋め込まれたコンポーネントを開発する場合は、どのシステムログを選択し、エンドユーザーに影響を与えることは不可能である、SLF4Jを使用して検討すべきです。一方、それは単純または別のアプリケーションがある場合は、
一つだけのログシステムを決定し、その後、SLF4Jを使用する必要はありません。あなたが製品を販売する際のlog4jを使用すると仮定することは、log4jのコールの数千人の顔を変更するためにJDK 1.8ロギングユーザーが必要です
私は、これは簡単なことではないと信じています。彼らはSLF4Jを使用して起動した場合でも、この変換は非常に簡単なものになります。
Logback
「信頼性、汎用性、迅速かつ柔軟なJavaロギング・フレームワーク。」、Logback
現在、三つのモジュールに分かれlogback：
logback-コア、
logback-古典
logback-アクセス。
logbackコアモジュールの他の二つのモジュールのための基礎です。
logback-classicがlog4jのの修正版です。
さらにlogback-古典的な完全な実装のSLF4JのAPIので、簡単なログにlog4jあるいはJDKロギングなどの他のシステムに変更することができます。
logback-アクセスアクセス・モジュールは、HTTPアクセスログ機能により供給されたサーブレットコンテナと統合します。
logbackを選んだ理由：
1. logbackの約10倍のlog4jより速く、少ないメモリを消費します。
2. logback-古典モジュールインターフェース直接SLF4Jを実装するので、我々はほぼゼロオーバーヘッドをlogbackに移動します。
3. logbackだけでなく、設定ファイルのXMLフォーマットをサポートし、また、設定ファイルグルーヴィーな形式をサポートしています。これとは対照的に、Groovyのスタイルの設定ファイルより直感的でシンプル。
4. logback-古典プロファイル更新を検出し、自動的にコンフィギュレーション・ファイルを再ロードすることができます。
我々はロガーを再開するためにアプリケーションを再起動する必要がないように5. logbackは優雅に、I / O例外から回復します。
プロファイルの上限に記載のlogbackは、古いログ・ファイルを自動的に削除するように設定することができます。
7. logbackは自動的にログファイルを圧縮することができます。
8. logback条件決意は、構成ファイル（IF-THEN-ELSE）を添加することができます。異なる開発環境（DEV、テスト、UAT ...）プロファイルの重複を避けてください。
9. logback以上のフィルタをもたらします。
スタックトレース10は、パッケージにはより多くの情報が含まれていますlogback。
11. logback-アクセスや桟橋、Tomcatの統合は、強力なHTTPアクセスジャーナルを提供します。
プロフィール：プロジェクトのsrcディレクトリにlogback.xmlを確立する必要があります。
注：（1）logbackは最初logback.groovyファイルを検索します。
見つからない場合は（2）、logback-のtest.xmlファイルを見つけようとし続けます。
（3）が見つからない場合は、logback.xmlファイルを見つけようとし続けて、
（コンソールに出力）（4）それでも見つからない場合は、デフォルトの設定。
Apacheのコモンズのログ
以前にJakarta Commonsのロギング（JCL）として知られているのApache Commonsのロギングは、アカウント軽量を考慮して、ログ（ログ）インタフェース（インタフェース）を提供されており、特定のログ・インプリメンテーション・ツールに依存しません。単純なログ操作の抽象化は、開発者が特定のログを達成するためのさまざまなツールを使用することができますミドルウェア/ロギングツール開発者に提供されます。ユーザーは、より高いレベルのツールを達成するために、ログの詳細のいくつかに精通していると想定されます。JCLは、このインタフェース近いLog4JのとLogKitを達成するために、単純なパッケージのために、Log4Jの、アバロンLogKit、およびJDK 1.4+などを含む他のロギングツールのインタフェースを提供します。
apacheの共通のログは、ログに共通のインターフェースを提供することです。ユーザーはlog4jのように、独自のJDKまたはロギング、共通のロギングが実行されているプログラムの実際の使用を見つけるために動的な検索、自動ログデータベースのメカニズムを通じてなり、具体的な実現などのサードパーティのロギング・コンポーネントを自由に選択できます。もちろん、簡単な内部コモン・ロギングがシンプルなロガーを達成があるが、非常に悪いです。そう頻繁に使用するのlog4jと組み合わせて、共通のロギングを使用します。それを使用する利点は、コードということではなく、共通のロギングにlog4jに依存している、と直接結合された特定のロギングプログラムを避けるため、必要なときに、あなたはサードパーティのライブラリを達成するために、ログを変更することができます。
共通のロギングの一般的なコードを使用します。