1

私たちのプロジェクトで頻繁に使用されている 1 つのライブラリには、そのクラスの変数を静的にしてはならないという制限があります。(ULCです)。私が理解している限りでは、それらすべてをシリアル化する必要があるためです。そして、このルールの問題点は、厳密ではなく、デバッグが非常に困難なバグの原因になる可能性があることです。

そのようなタイプの静的変数を検出するための Checkstyle 用のモジュールを作成します (おそらく、カスタマイズ可能な正規表現によって検出されます)。そして、このチェックが他の開発者にとってどれほど必要かを知る必要があります。

質問は次のとおりです。ある型の変数が静的であってはならない一般的な状況は何ですか?

4

2 に答える 2

1

まず、適切なオブジェクト指向設計により、メソッド/フィールドを静的にする決定を通知する必要があります。

次に、リクエストがすべて別のスレッドで処理される Web アプリケーションでは、静的メソッド/フィールドの使用方法に十分注意する必要があります。静的メソッドが呼び出し全体で状態を維持する場合 (たとえば、静的フィールドを使用してカウントを保持することにより)、スレッド化の問題が発生する可能性があります。これは、あるリクエストが静的メソッドを呼び出し、そのメソッドを呼び出す別のスレッドによって実行中に停止される可能性があるために発生します。最初の呼び出しで共通リソースが変更されたが終了しなかった場合、2 回目の呼び出しによって最初の実行の進行状況が損なわれる可能性があります。

于 2010-12-01T14:31:35.977 に答える
0

簡単な答え: 型がスレッドセーフでない方法で変更される場合、その型を静的インスタンスとして使用してはなりません。これが、ULCがこのようにタイプを使用しないことを推奨している理由だと思います(シリアライゼーションのためではありません)。

残念ながら、これを checkstyle などでチェックするのは非常に困難です。たとえば、HashMap はスレッドセーフではありません。ただし、インスタンスを構築し、クラスのロード中に静的に設定し、その後マップからのみ読み取る場合、これは HashMap の安全な使用法です (クラスローディングはセットアップ時に外部スレッドの安全性を保証し、後で変更されることはないため) .

于 2010-12-01T16:39:01.050 に答える