作業キューがあり、何千もの作業項目が存在する可能性があるとします。また、さまざまな作業項目の更新がシステムに反映され続けると想定します。同じ作業項目に対して複数の更新を取得した場合は、明らかにロックする必要があります。
この状況では、システムが一度に2000（またはいくつかの多数）の更新を受信する可能性があるため、JVMがさまざまなオブジェクトに対して2000のロックを保持する必要がある状況に簡単に遭遇する可能性があります。
JVMのパフォーマンスが大幅に低下しますか？パフォーマンスを低下させないためにJVMが一度に保持できるロックの最大数はありますか。
ハッシュ手法を使用して、ロックの数が増えるのを防ぐことができると理解しています。
各ロックは、それを保持しているオブジェクトを格納するだけです。12質問の最初の部分（JVMが保持できるロックの数）は、JVMが格納できるロックの数を尋ねるようなものです。量はメモリによって制限されます。他の人が指摘しているように、パフォーマンスはロックの競合によって最も影響を受けます。
からのクラスを使用してjava.util.concurrent、安全性とパフォーマンスのために作成されたロックとワークキューを構築および保存します。「 JavaConcurrencyinPractice」という本を強くお勧めします。
マルチコア シナリオでのロックには、アトミック メモリ操作が含まれます。つまり、1 つのコアが別のコアによって書き込まれたデータを (書き込まれた後に) 参照します。このデータは、1 つのコアによってメモリにプッシュされ (他のすべてのコアのキャッシュに、この値について知っていることはすべて無効であり、更新する必要があることを伝えます)、他のコアで読み込まれる必要があります。これが発生する速度は、CPU アーキテクチャとその実装によって大きく異なります。一般に、シングル ソケット マシンはマルチ ソケットよりも高速である必要があります。
したがって、SimonC が言ったように、テストを作成する必要があります。