A
次の特性を持つサードパーティ クラスを考えてみましょう。
その実装のほとんどは非公開で非常に複雑であるため、拡張することはできますが、合理的に変更することはできません。
A
不必要に呼び出すべきではない非常に高価なコンストラクターがあります-私の場合、後で使用するためにデータの巨大なルックアップテーブルを構築します。これは、デコレータ クラスを のドロップイン置換として作成すること
A
は問題外であることを意味します。デコレータは、そのコンストラクタから継承しA
て呼び出す必要があるためです。A
はサードパーティ コードによって使用されるため、代わりにプロキシ クラスを使用することはできません。他のコードは のインスタンスを想定A
しており、それを取得する必要があります。A
大量のレポートを生成するために多くのwrableをfrabbleする、非常に高価なレポート メソッドを多数提供します。これらのメソッドは、ローカルで使用される結果を生成しません。理論的には非同期である可能性がありますが、残念ながらそうではありません。
A
お互いを呼び出す方法- たくさん。実装は不透明で、常に流動的です。
A
リフレクション ポスト インスタンス化を使用して物事をスリム化するなどのハックは問題外です。A
スレッドセーフではありません-実際には...
私は自分のプロジェクトでボトルネックになるポイントに達したので、実際のワラブルのフラブリングを別のスレッドにプッシュすることを望んA
で子クラスを作成しました。オブジェクトを単一スレッドのエグゼキュータ サービスに送信するためだけに、すべてのパブリック メソッドをオーバーライドしました。次に、それぞれがワーカー スレッドから適切なメソッドを実行します。B
A
Runnable
Runnable
super
残念ながら、独自の public メソッドを頻繁に呼び出しA
ます。通常は問題ありませんが、私の場合、スーパークラスはからメソッドを呼び出しています。メソッドは実際の実行を延期し、新しいタスクをエグゼキューター サービスに送信するため、パフォーマンスと正確性の両方の問題が発生するため、これは大きな問題です。B
B
Thread.currentThread()
私の解決策は、すべてのメソッドの結果をチェックしてB
、ワーカー スレッドからの呼び出しがsuper
新しいタスクとして送信されるのではなく、メソッドに直接委任されるようにすることでした。
だから今、私はそれThread.currentThread()
がパフォーマンスの問題になっているところにいます。おそらく、あまりにも頻繁に呼び出されるネイティブメソッドであるためです。
スーパークラスやワーカー スレッドからスレッドセーフな方法でメソッド呼び出しを確認するより高速な方法はありますか?
A
のぐらつきを別のスレッドにプッシュできるようにする代替設計はありますか?A
サードパーティのコードであるため、ほとんど閉じ込められているようです...