この記事の焦点は、マルチスレッドアプリケーションのパフォーマンスの問題にあります。最初にパフォーマンスとスケーラビリティを定義し、次にAmdahlルールを慎重に研究します。次のコンテンツでは、ロック競争を減らすためにさまざまな技術的方法を使用する方法と、コードでそれを実装する方法を検討します。
1。パフォーマンス
マルチスレッドを使用してプログラムのパフォーマンスを向上させることができることは誰もが知っており、この背後にある理由は、マルチコアCPUまたは複数のCPUがあることです。各CPUコアはそれ自体でタスクを完了することができるため、互いに独立して実行できる一連の小さなタスクに大きなタスクを破ることで、プログラムの全体的なパフォーマンスを向上させることができます。例を挙げることができます。たとえば、ハードディスク上のフォルダー内のすべての写真のサイズを変更するプログラムがあり、マルチスレッドテクノロジーの適用によりパフォーマンスが向上する可能性があります。単一のスレッドアプローチを使用すると、すべての画像ファイルのみを順番に移動し、変更を実行できます。 CPUに複数のコアがある場合、そのうちの1つだけを使用できることは間違いありません。マルチスレッドを使用して、プロデューサースレッドをファイルシステムをスキャンして各画像をキューに追加し、複数のワーカースレッドを使用してこれらのタスクを実行できます。ワーカースレッドの数がCPUコアの総数と同じである場合、すべてのタスクが実行されるまで、各CPUコアが作業を行うことを確認できます。
より多くのIO待機を必要とする別のプログラムの場合、マルチスレッドテクノロジーを使用して全体的なパフォーマンスを改善することもできます。特定のWebサイトのすべてのHTMLファイルをクロールし、ローカルディスクに保存する必要があるようなプログラムを作成したいとします。このプログラムは、特定のWebページから開始し、このWebページのこのWebサイトへのすべてのリンクを解析し、これらのリンクを順番にクロールして、繰り返します。リモートWebサイトへのリクエストを開始してからすべてのWebページデータを受け取るまでに待つのに時間がかかるため、このタスクを実行のために複数のスレッドに引き渡すことができます。受信したHTMLページを1つまたはもう少しスレッドに解析し、見つかったリンクをキューに入れて、他のすべてのスレッドをリクエストする責任を負わせます。前の例とは異なり、この例では、CPUコアの数よりも多くのスレッドを使用していても、パフォーマンスの改善を取得できます。
上記の2つの例は、短い時間枠でできるだけ多くのことを行うことであることを示しています。これはもちろん、パフォーマンスという用語の最も古典的な説明です。しかし、同時に、スレッドを使用すると、プログラムの応答速度をうまく改善することもできます。このようなグラフィカルインターフェイスアプリケーションがあり、入力ボックスと入力ボックスの下に「プロセス」という名前のボタンがあると想像してください。ユーザーがこのボタンを押すと、アプリケーションはボタンのステータスを再実行する必要があります（ボタンを押したように見え、左マウスボタンがリリースされたときに元の状態に戻ります）、ユーザーの入力の処理を開始します。このタスクがユーザー入力を処理するのに時間がかかる場合、シングルスレッドプログラムは、ユーザーがマウスイベントをクリックしたり、オペレーティングシステムから送信されたイベントを移動するマウスポインターなど、他のユーザーインプットアクションに応答し続けることができません。これらのイベントへの応答は、応答する独立したスレッドである必要があります。
スケーラビリティとは、プログラムがコンピューティングリソースを追加することにより、より高いパフォーマンスを得ることができることを意味します。マシンのCPUコアの数が限られているため、多くの画像のサイズを調整する必要があると想像してください。スレッドの数を増やすと、それに応じてパフォーマンスが常に向上するとは限りません。それどころか、スケジューラはより多くのスレッドの作成とシャットダウンに責任を負う必要があるため、CPUリソースも占有し、パフォーマンスを低下させる可能性があります。
1.1 AMDAHLルール
前の段落では、場合によっては、コンピューティングリソースを追加すると、プログラムの全体的なパフォーマンスが向上する可能性があると述べました。追加のリソースを追加すると、パフォーマンスの改善量を計算するには、プログラムのどの部分が連続的に（または同期して）実行され、どの部分が並行して実行されるかを確認する必要があります。 B（たとえば、実行する必要があるコードの行の数）と同期的に実行する必要があるコードの割合を定量化し、CPUのコアの総数をNとして記録する場合、AMDAHLの法則に従って、得られるパフォーマンス改善の上限は次のとおりです。
nが無限になる傾向がある場合、（1-b）/nは0に収束します。したがって、この式の値を無視できます。したがって、パフォーマンス改善ビットカウントは1/bに収束します。ここで、bは同期して実行する必要があるコードの割合を表します。 Bが0.5に等しい場合、プログラムのコードの半分が並行して実行できず、0.5の逆数が2であることを意味します。今すぐプログラムを変更したとし、変更後、0.25コードのみを同期して実行する必要があります。現在、1/0.25 = 4は、プログラムが多数のCPUを使用してハードウェアで実行される場合、シングルコアハードウェアよりも約4倍高速になることを意味します。
一方、AMDAHL法を通じて、プログラムが取得するスピードアップターゲットに基づいている必要があると同期コードの割合を計算することもできます。 100倍のスピードアップを達成したい場合、1/100 = 0.01は、プログラムが同期して実行するコードの最大数が1％を超えることができないことを意味します。
AMDAHLの法則を要約するために、CPUを追加することで得られる最大のパフォーマンス改善は、プログラムの割合がコードの一部を同期して実行するかによって異なります。実際には、この比率を計算することは必ずしも容易ではありませんが、大規模な商業システムアプリケーションに直面することは言うまでもなく、AMDAHLの法律は重要なインスピレーションを与えます。つまり、同期して実行する必要があるコードを考慮し、コードのこの部分を減らす必要があります。
1.2パフォーマンスへの影響
ここに記事が書いているように、スレッドを追加することでプログラムのパフォーマンスと応答性が向上する可能性があると述べています。しかし、一方で、これらの利点を達成することは容易ではなく、価格も必要です。スレッドの使用もパフォーマンスの改善に影響します。
まず、最初の影響は、スレッドの作成の時刻から来ます。スレッドの作成中、JVMは、基礎となるオペレーティングシステムから対応するリソースを適用し、スケジューラのデータ構造を初期化して実行スレッドの順序を決定する必要があります。
スレッドの数がCPUコアの数と同じ場合、各スレッドはコアで実行され、頻繁に中断されないようにします。しかし、実際には、プログラムが実行されている場合、オペレーティングシステムには、CPUが処理する必要がある独自の操作もあります。したがって、この場合でも、スレッドが中断され、オペレーティングシステムが操作を再開するのを待ちます。スレッドカウントがCPUコアの数を超えると、状況が悪化する可能性があります。この場合、JVMのプロセススケジューラは特定のスレッドを中断して、他のスレッドが実行できるようにします。スレッドが切り替えられると、実行中のスレッドの現在の状態を保存する必要があり、次に実行されるときにデータ状態を復元できるようにします。それだけでなく、スケジューラは独自の内部データ構造も更新します。これには、CPUサイクルも必要です。これはすべて、スレッド間のコンテキストを切り替えるとCPUコンピューティングリソースが消費されるため、単一のスレッドケースのパフォーマンスと比較してパフォーマンスがオーバーヘッドをもたらすことを意味します。
マルチスレッドプログラムによってもたらされる別のオーバーヘッドは、共有データの同期アクセス保護からのものです。同期されたキーワードを同期保護に使用することも、揮発性キーワードを使用して複数のスレッド間でデータを共有することもできます。複数のスレッドが共有データ構造にアクセスしたい場合、競合が発生します。この時点で、JVMは、どのプロセスが最初であり、どのプロセスが背後にあるかを決定する必要があります。実行するスレッドが現在実行中のスレッドではない場合、スレッドの切り替えが発生します。現在のスレッドは、ロックオブジェクトを正常に取得するまで待つ必要があります。 JVMは、この「待機」を実行する方法を決定できます。 JVMがロックされたオブジェクトを正常に取得することが短くなると予想している場合、JVMは、成功するまでロックされたオブジェクトを絶えず取得しようとするなど、積極的な待機方法を使用できます。この場合、プロセスコンテキストの切り替えを比較する方が速いため、この方法はより効率的になる可能性があります。待機スレッドを実行キューに戻すと、追加のオーバーヘッドがもたらされます。
したがって、ロック競争によって引き起こされるコンテキストの切り替えを避けるために最善を尽くさなければなりません。次のセクションでは、このような競争の発生を減らす2つの方法について説明します。
1.3ロック競争
前のセクションで述べたように、2つ以上のスレッドでロックへの競合アクセスは、スケジューラが積極的な待機状態に入るように強制するか、待機状態を実行させて2つのコンテキストスイッチを引き起こすため、追加の計算オーバーヘッドをもたらします。ロック競争の結果を緩和できる場合があります。
1。ロックの範囲を削減します。
2。取得する必要があるロックの頻度を減らします。
3.同期するのではなく、ハードウェアでサポートされている楽観的なロック操作を使用してみてください。
4.同期して可能な限り使用してみてください。
5。オブジェクトキャッシュの使用を減らします
1.3.1同期ドメインの削減
コードが必要以上にロックを保持している場合、この最初の方法を適用できます。通常、現在のスレッドがロックを保持する時間を短縮するために、同期領域から1つ以上のコードを移動できます。同期領域で実行されるコードが少ないほど、現在のスレッドがロックを早期にリリースし、他のスレッドがより早くロックを取得できるようにします。これは、AMDAHLの法則と一致しています。これにより、同期する必要があるコードの量が減少するためです。
より良い理解のために、次のソースコードを見てください。
パブリッククラスReducelockDurationは実行可能{private static final int number_of_threads = 5; private static final Map <String、integer> map = new Hashmap <String、integer>（）; public void run（）{for（int i = 0; i <10000; i ++）{synchronized（map）{uuid randomuuid = uuid.randomuuid（）;整数値= integer.valueof（42）; string key = randomuuid.toString（）; map.put（key、value）; } thread.yield（）; }} public static void main（string [] args）throws arturtedexception {thread [] swreets = newスレッド[number_of_threads]; for（int i = 0; i <number_of_threads; i ++）{threads [i] = new swerch（new ReducelockDuration（））; } long startmillis = system.currenttimemillis（）; for（int i = 0; i <number_of_threads; i ++）{threads [i] .start（）; } for（int i = 0; i <number_of_threads; i ++）{threads [i] .jein（）; } system.out.println（（system.currenttimemillis（） - startmillis）+"ms"）; }}上記の例では、5つのスレッドが共有マップインスタンスにアクセスするために競合させます。 1つのスレッドのみがマップインスタンスに同時にアクセスできるように、同期された保護されたコードブロックにマップにキー/値を追加する操作を配置します。このコードを注意深く見ると、キーと値を計算するコードの数少ない文が同期して実行する必要がないことがわかります。キーと値は、現在このコードを実行しているスレッドにのみ属します。それは現在のスレッドにとってのみ意味があり、他のスレッドによって変更されません。したがって、これらの文章を同期保護から移動できます。次のように：
public void run（）{for（int i = 0; i <10000; i ++）{uuid randomuuid = uuid.randomuuid（）;整数値= integer.valueof（42）; string key = randomuuid.toString（）;同期（map）{map.put（key、value）; } thread.yield（）; }}同期コードを削減する効果は測定可能です。私のマシンでは、プログラム全体の実行時間は420msから370msに短縮されました。同期保護ブロックから3行のコードを移動するだけで、プログラムの実行時間を11％短縮できます。 Thread.yield（）コードは、Thread Context Switchingを誘導するためです。このコードは、現在のスレッドが現在使用されているコンピューティングリソースを引き渡し、実行するのを待っている他のスレッドが実行できるようにjvmに指示するためです。また、これはより多くのロック競争につながります。これがそうでない場合、スレッドは特定のコアをより長く占有し、それによりスレッドのコンテキストの切り替えを減らすためです。
1.3.2スプリットロック
ロック競争を減らす別の方法は、ロック保護コードのブロックを多くの小さな保護ブロックに広めることです。この方法は、プログラムにロックを使用して複数の異なるオブジェクトを保護する場合に機能します。プログラムを介していくつかのデータをカウントし、複数の異なる統計インジケーターを保持して基本カウント変数（長いタイプ）で表現するために単純なカウントクラスを実装したいとします。私たちのプログラムはマルチスレッドであるため、これらのアクションは異なるスレッドから来るため、これらの変数にアクセスする操作を同期的に保護する必要があります。これを達成する最も簡単な方法は、これらの変数にアクセスする各関数に同期されたキーワードを追加することです。
public static class CounterOnelockを実装します{private long customercount = 0; Private Long ShippingCount = 0; public synchronized void incrementCustomer（）{customercount ++; } public synchronized void incrementshipping（）{shippingcount ++; } public synchronized long getCustomerCount（）{return CustomerCount; } public synchronized long getShippingCount（）{return ShippingCount; }}これは、これらの変数を変更するたびに、他のカウンターインスタンスへのロックを引き起こすことを意味します。他のスレッドが別の異なる変数の増分メソッドを呼び出したい場合、彼らはそれを完了する機会がある前に、前のスレッドがロックコントロールをリリースするのを待つことしかできません。この場合、異なる変数ごとに個別の同期保護を使用すると、実行効率が向上します。
public static class counterseparatelockはcounter {private static final object customerlock = new object（）; private static final object shippinglock = new object（）;プライベートLONG CUSTORERCOUNT = 0; Private Long ShippingCount = 0; public void incrementCustomer（）{synchronized（customerlock）{customercount ++; }} public void incrementshipping（）{synchronized（shippinglock）{shippingcount ++; }} public long getCustomerCount（）{synchronized（customerlock）{return customercount; }} public long getShippingCount（）{synchronized（shippinglock）{return shippingcount; }}}この実装では、各カウントメトリックに個別の同期オブジェクトが導入されます。したがって、スレッドが顧客数を増やしたい場合、顧客数が増加する別のスレッドが完了するのを待つ必要があります。
次のクラスを使用して、スプリットロックによってもたらされるパフォーマンスの改善を簡単に計算できます。
public class locksplitting runnable {private static final int number_of_threads = 5;プライベートカウンターカウンター;パブリックインターフェイスカウンター{void incrementCustomer（）; void incrementShipping（）; long getCustomerCount（）; long getShippingCount（）; } public static class counterElock実装カウンター{...} public static class counterseparatelock実装{...} public locksplitting（counter counter）{this.counter = counter; } public void run（）{for（int i = 0; i <100000; i ++）{if（threadlocalrandom.current（）。nextboolean（））{counter.incrementCustomer（）; } else {counter.incrementshipping（）; }}} public static void main（string [] args）throws arturtedexception {thread [] swreets = newスレッド[number_of_threads];カウンターカウンター= new CounterOnelock（）; for（int i = 0; i <number_of_threads; i ++）{threads [i] = new swerch（new locksplitting（counter））; } long startmillis = system.currenttimemillis（）; for（int i = 0; i <number_of_threads; i ++）{threads [i] .start（）; } for（int i = 0; i <number_of_threads; i ++）{threads [i] .jein（）; } system.out.println（（system.currenttimemillis（） - startmillis） + "ms"）; }}私のマシンでは、単一のロックの実装方法には平均56ミリ秒かかり、2つの個別のロックの実装は38ミリ秒です。時間のかかる時間は約32％削減されます。
改善する別の方法は、さまざまなロックで読み書きを保護するためにさらに進むことさえできることです。元のカウンタークラスは、それぞれカウントインジケーターを読み書きする方法を提供します。ただし、実際、読み取り操作は同期保護を必要としません。複数のスレッドが現在のインジケーターの値を並行して読み取ることができることを保証できます。同時に、書き込み操作は同期的に保護する必要があります。 java.util.concurrentパッケージは、この区別を簡単に実現できるReadWritelockインターフェイスの実装を提供します。
ReentrantreadWriteLockの実装は、2つの異なるロックを維持し、1つは読み取り操作を保護し、もう1つは書き込み操作を保護します。両方のロックには、ロックを取得および解放するための操作があります。書き込みロックは、読み取りロックを取得しない場合にのみ正常に取得できます。逆に、書き込みロックが取得されない限り、読み取りロックは複数のスレッドで同時に取得できます。このアプローチを実証するために、次のカウンタークラスでは、次のようにreadwritelockを使用します。
public static class counterreadwritelock counter {private final reintrantreadwritelock customerlock = new Reentrantreadwritelock（）;プライベートファイナルロックcustomerwritelock = customerlock.writeLock（）;プライベートファイナルロックcustomerReadLock = customerLock.readLock（）;プライベートファイナルReentrantreadWriteLock ShippingLock = new ReentranTreadWriteLock（）;プライベートファイナルロックshiptionwritelock = shippinglock.writelock（）;プライベートファイナルロックShippingLeadLock = ShippingLock.ReadLock（）;プライベートLONG CUSTORERCOUNT = 0; Private Long ShippingCount = 0; public void incrementCustomer（）{customerWriteLock.Lock（）; customercount ++; customerwriteLock.unlock（）; } public void incrementShipping（）{shippingWritElock.Lock（）; ShippingCount ++; shiptionwriteLock.unlock（）; } public long getCustomerCount（）{customerReadLock.Lock（）; long count = customercount; CustomerReadLock.unlock（）;返品数; } public long getShippingCount（）{shippingReadLock.Lock（）; long count = shippingcount; shippingReadLock.unlock（）;返品数; }}すべての読み取り操作は読み取りロックによって保護され、すべての書き込み操作は書き込みロックによって保護されます。プログラムで実行される読み取り操作が書き込み操作よりもはるかに大きい場合、この実装は、読み取り操作を同時に実行できるため、前のセクションよりも大きなパフォーマンスの改善をもたらす可能性があります。
1.3.3分離ロック
上記の例は、単一のロックを複数の個別のロックに分離する方法を示しており、各スレッドが変更しようとしているオブジェクトのロックを取得できるようにします。しかし、一方で、この方法はプログラムの複雑さも増し、不適切に実装された場合、デッドロックを引き起こす可能性があります。
分離ロックは剥離ロックと同様の方法ですが、分離ロックは、異なるコードスニペットまたはオブジェクトを保護するためのロックを追加することです。一方、分離ロックは、異なる範囲の値を保護するために異なるロックを使用することです。 JDKのjava.util.concurrentパッケージのConcurrenthashmapは、このアイデアを使用して、ハッシュマップに大きく依存するプログラムのパフォーマンスを改善します。実装に関しては、同期的に保護されたハッシュマップをカプセル化する代わりに、CONCURRENTHASHMAPは内部で16種類のロックを使用します。 16個のロックのそれぞれは、バケットビットの10分の1（バケツ）への同期アクセスを保護する責任があります。このようにして、異なるスレッドが異なるセグメントにキーを挿入したい場合、対応する操作は異なるロックによって保護されます。ただし、特定の操作の完了には、1つのロックではなく複数のロックが必要になるなど、いくつかの悪い問題が発生します。マップ全体をコピーする場合は、完了するには16個のロックすべてを取得する必要があります。
1.3.4原子操作
ロック競争を減らすもう1つの方法は、他の記事の原則について詳しく説明する原子操作を使用することです。 Java.util.concurrentパッケージは、一般的に使用されるいくつかの基本データ型に対して、原子的にカプセル化されたクラスを提供します。原子動作クラスの実装は、プロセッサが提供する「比較順列」関数（CAS）に基づいています。 CAS操作は、現在のレジスタの値が操作によって提供される古い値と同じ場合にのみ、更新操作を実行します。
この原則を使用して、変数の値を楽観的な方法で増やすことができます。スレッドが現在の値を知っている場合、CAS操作を使用して増分操作を実行しようとします。この期間中に他のスレッドが変数の値を変更した場合、スレッドによって提供されるいわゆる電流値は実際の値とは異なります。この時点で、JVMは現在の値を取り戻して再試行しようとし、成功するまでもう一度繰り返します。ループ操作はいくつかのCPUサイクルを無駄にしますが、これを行うことの利点は、同期制御の形態を必要としないことです。
以下のカウンタークラスの実装では、アトミック操作を使用しています。ご覧のとおり、使用される同期コードはありません。
public static class counter原子化物体はカウンター{private atomiclong customercount = new Atomiclong（）; Private Atomiclong ShippingCount = new AtomicLong（）; public void incrementCustomer（）{customercount.incrementAndget（）; } public void incrementShipping（）{shippingcount.incrementAndget（）; } public long getCustomErcount（）{return CustomerCount.get（）; } public long getShippingCount（）{return ShippingCount.get（）; }}Counterseparatelockクラスと比較して、平均ランニング時間は39msから16msに短縮されており、これは約58％です。
1.3.5ホットスポットコードセグメントを避けてください
典型的なリストの実装は、コンテンツ内の変数を維持することにより、リスト自体に含まれる要素の数を記録します。リストから要素が削除または追加されるたびに、この変数の値が変更されます。単一の読み取りアプリケーションでリストが使用されている場合、この方法は理解できます。 Size（）を呼び出すたびに、最後の計算後に値を返すことができます。このカウント変数がリストによって内部的に維持されていない場合、各size（）への呼び出しはリストを反転させて要素の数を計算します。
多くのデータ構造で使用されるこの最適化方法は、マルチスレッド環境にある場合に問題になります。複数のスレッド間でリストを共有し、複数のスレッドが同時に要素をリストに追加または削除し、大きな長さをクエリするとします。この時点で、カウント変数内部リストは共有リソースになるため、すべてのアクセスを同期して処理する必要があります。したがって、カウント変数は、リストの実装全体でホットスポットになります。
次のコードスニペットは、この問題を示しています。
public static class carrepositorywithcounterはCarrepository {private Map <string、car> cars = new Hashmap <String、car>（）;プライベートマップ<文字列、car>トラック= new hashmap <string、car>（）;プライベートオブジェクトcarcountsync = new object（）; private int carcount = 0; public void addcar（car car）{if（car.getlicencePlate（）。startswith（ "c"））{synchronized（cars）{car foundcar = cars.get（car.getlicenceplate（））; if（foundCar == null）{cars.put（car.getlicencePlate（）、car）;同期（carcountsync）{carcount ++; }}}} else {synchronized（trucks）{car foundcar = trucks.get（car.getlicencePlate（））; if（foundcar == null）{trucks.put（car.getlicenceplate（）、car）;同期（carcountsync）{carcount ++; }}}}}} public int getCarcount（）{synchronized（carcountsync）{return carcount; }}}CarrePositoryの上記の実装には内部に2つのリスト変数があり、1つは洗車要素を配置するために使用され、もう1つはトラック要素の配置に使用されます。同時に、これら2つのリストの合計サイズを照会する方法を提供します。使用される最適化方法は、車の要素が追加されるたびに、内部カウント変数の値が増加することです。同時に、増分操作は同期によって保護され、カウント値を返すために同じことが当てはまります。
この追加のコード同期オーバーヘッドを回避するには、以下のCarrePositoryの別の実装を参照してください。内部カウント変数は使用されなくなりますが、車の総数を返す方法でこの値をリアルタイムでカウントします。次のように：
public static class carrepositorywithoutcounterはCarrePository {private Map <String、car> cars = new Hashmap <String、car>（）;プライベートマップ<文字列、car>トラック= new hashmap <string、car>（）; public void addcar（car car）{if（car.getlicencePlate（）。startswith（ "c"））{synchronized（cars）{car foundcar = cars.get（car.getlicenceplate（））; if（foundCar == null）{cars.put（car.getlicencePlate（）、car）; }}} else {synchronized（trucks）{car foundcar = trucks.get（car.getlicencePlate（））; if（foundcar == null）{trucks.put（car.getlicenceplate（）、car）; }}}}} public int getCarcount（）{synchronized（cars）{synchronized（trucks）{return cars.size（） + trucks.size（）; }}}}ここで、GetCarCount（）メソッドのみで、2つのリストへのアクセスには同期保護が必要です。以前の実装と同様に、新しい要素が追加されるたびに同期オーバーヘッドは存在しなくなりました。
1.3.6オブジェクトのキャッシュの再利用を避けます
Java VMの最初のバージョンでは、新しいキーワードを使用して新しいオブジェクトを作成するオーバーヘッドは比較的高く、多くの開発者はオブジェクトの再利用モードを使用することに慣れています。何度も何度もオブジェクトの作成を繰り返しないようにするために、開発者はバッファープールを維持します。オブジェクトインスタンスを作成するたびに、バッファープールに保存できます。次回他のスレッドを使用する必要があるときは、バッファープールから直接検索できます。
一見、この方法は非常に合理的ですが、このパターンはマルチスレッドアプリケーションで問題を引き起こす可能性があります。オブジェクトのバッファープールは複数のスレッド間で共有されるため、オブジェクトにアクセスするときにすべてのスレッドの操作が共有されるため、同期保護が必要です。この同期のオーバーヘッドは、オブジェクト自体の作成よりも大きくなります。もちろん、あまりにも多くのオブジェクトを作成すると、Garbage Collectionの負担が増加しますが、これを考慮しても、オブジェクトキャッシュプールを使用するよりもコードを同期することでもたらされるパフォーマンスの改善を回避する方が良いです。
この記事で説明されている最適化スキームは、実際に適用されたときに可能な各最適化方法を慎重に評価する必要があることを再度示しています。未熟な最適化ソリューションは表面上で意味をなすように見えますが、実際にはパフォーマンスのボトルネックになる可能性があります。