Javaロギングシステム（8）のベストプラクティス

Javaロギングフレームワークの共通の関係

Log4jの1のlog4j 2のlog4j 2のlog4j 1と互換性がない、大きな変化を遂げました。
LogbackはSLF4Jの使用を協力しなければなりません。LogbackとSLF4J同じ人なので、その互換性は自明です。
より一般的な使用は、組み合わせ、コモンズロギングおよびLog4jの組合せで使用Logback SLF4Jとの組み合わせです。

プロジェクトのログフレーム選択を選択します

新しいプロジェクトの場合はSLF4JとLogbackの組み合わせをお勧めします次のように、これはいくつかの利点があります。

決定SLF4JのSLF4J実装メカニズムより制限の少ない、より広い範囲を使用しています。コンパイル時にSLF4Jので、静的結合LOG地元の図書館では、より良いロギング・コモンズより汎用性の高いことができます。
Logbackより優れた性能を持っています。Logbackは、請求：このような記録動作ログステートメントかどうかを決定するようないくつかのキー操作が、その性能は大幅に改善されています。Log4Jの30ナノ秒で必要とされている間、この動作は、Logback 3ナノ秒を必要とします。レコーダ（ロガー）より速い速度を作成LogBack：13ミリ秒、23ミリ秒は、Log4Jのに必要とされます。さらに重要なことは、既存のレコーダーだけで94ナノ秒と、1月23日までの時間を短縮するために2234ナノ秒Log4Jのニーズを取得します。パフォーマンスの改善と比較して7月には重要です。
高いオーバーヘッドロギングコモンズ

コモンズのログログ情報を構築する際のオーバーヘッドを低減するために＃、それは一般的に行われている
 IF （log.isDebugEnabled（））{ 
  log.debug（「ユーザー名：」+ 
    user.getName（） +「販売製品ID：」+ good.getId（））; 
} 

＃SLF4Jキャンプで、あなただけ実行する必要があります。
log.debug（ "ユーザ名：{}、販売製品は、上記のIDを述べた：{}" 、user.getName（）、good.getId（）） ; 

SLF4Jは、ログを構築するコストは、それがオーバーヘッド削減、このログを表示する必要性を認識し、メモリ・カップ、プレースホルダの使用に置いた後、＃つまり、コードがより簡潔です

無料Logbackドキュメント。すべてのドキュメントは、包括的なLogbackは部分的にしか自由なドキュメントとしてLog4Jのとは違って、無料で提供し、有料の文書を購入するユーザーが必要となります。

いくつかのベストプラクティス：

常にではなく、特定のログの実装よりも、ログファサードを使用

前に述べたように、ログファサードの使用が簡単に特定のログを達成するために切り替えることができます。さらに、依存プロジェクト、異なるログファサードの使用、複数のも容易に同じ実装でアダプタに転送することができる場合。依存プロジェクトが異なるログの実装の数を使用している場合、それはより厄介です。具体的には、継続使用JCLにはお勧めしません、Log4jの-APIまたはSLF4Jを使用することをお勧めします。

ただ、従属ログの実装を追加

プロジェクトでは、ログの実装は強く、ランタイム範囲を設定することを推奨依存し、オプションに設定されています。例えば、SLF4Jログファサードとしてプロジェクトで使用され、その後、Mavenの依存関係を追加使用し、その後、実装としてLog4j2を使用する場合、この設定：

<依存性> 
    <のgroupId> org.apache.logging.log4j </のgroupId> 
    <たartifactId> log4jのコア</たartifactId> 
    <バージョン> $ {log4j.version} </バージョン> 
    <スコープ>実行</スコープ> 
    <オプション> 真 </オプション> 
</依存> 
<依存性> 
    <のgroupId> org.apache.logging.log4j </のgroupId> 
    <たartifactId>のlog4j-SLF4J-IMPL </たartifactId> 
    <バージョン> $ {log4j.version} </バージョン> 
    <スコープ>ランタイム</スコープ> 
    <オプション> 真 </オプション> 
</依存関係>

プロジェクトは、特定のログの実装を使用する必要があることは間違いありません、LogbackまたはLog4j2をお勧めします。あなたが依存プロジェクト、直流ログの実装の使用をサポートしていません使用してログインファサードを持っている場合は、適切なブリッジ依存関係を追加します。

オプションに設定する必要があり、特定のログに依存して、実行時のスコープの使用

オプションを設定し、依存配信されていないので、あなたは、このLIBを使用libにプロジェクトや他のプロジェクトであれば、不要なログ実装の導入に依存することはありません。
実行時に設定する範囲、プロジェクトで開発を防ぐために直接ログファサードクラスを使用せずに、実装クラスをログに記録します。

必要に応じて、サードパーティのライブラリの依存関係がログImpementationに依存削除

これは非常に一般的な問題であり、サードパーティのライブラリの開発者は必ずしもブリッジは、オプションに設定されている特定のログを達成したり頼らないであろう、そして、あなたのプロジェクトは、これらの依存関係を継承-特定のロギング実装を使用したいという限りません例えば、彼はそれは恥ずかしいです、あなたはLogbackを使用したい、Log4jのを依存していました。第三者が別のブリッジと異なるログ・インプリメンテーションの使用に依存している場合はさらに、環を形成しても非常に簡単です。
この場合、推奨されるアプローチは、これらのすべてが唯一のサードパーティのライブラリは、顔のログファサードを頼っ保持、ログの実装とブリッジに依存除外するために除外使用することです。

たとえば、この問題に対処するには、no良いアリJStormは、Logbackとlog4jのオーバーSLF4Jへの依存を導入jstorm依存しているあなたはLog4jのか、他のログは、独自のプロジェクトで実装を使用したい場合、あなたは除外を追加する必要があります。

<依存性> 
    <のgroupId> com.alibaba.jstorm </のgroupId> 
    <たartifactId> jstormコア</たartifactId> 
    <バージョン> 2.1.1 </バージョン> 
    <除外> 
        <除外> 
            <のgroupId> org.slf4j </のgroupId > 
            <たartifactId> log4jのオーバーSLF4J </たartifactId> 
        </除外> 
        <除外> 
            <のgroupId> ch.qos.logback </のgroupId> 
            <たartifactId> logback-古典</たartifactId> 
        </除外> 
    </除外> 
</依存関係>

参考ます。https：//zhuanlan.zhihu.com/p/24275518