私は古典的なエンタープライズ アプリケーションについて話しています。通常、ある種のアプリケーション サーバーまたはコンテナーでホストされます。エンティティ、サービス、プレゼンテーション/UI、およびリレーショナル ストレージだけです。
synchronizedそのようなアプリケーションで (メソッドまたはブロックのいずれかの) キーワードを見るたびに、私は非常に疑わしくなります。私の意見では、これは基本的なアーキテクチャの概念 (たとえば、ドメイン モデルが複数のクライアント間で共有されていないなど) を理解していないことの兆候であるか、さらに悪いことに、アーキテクチャが実際には非常に失敗している兆候です。
ここで私の考え方を共有しますか？それとも私は完全に軌道から外れていますか？従来のエンタープライズ アプリケーションで実際に同期が必要なユース ケースはありますか?
ビジネスロジックコードについては同意しますが、エンタープライズアプリケーションには技術コードもあり、共有された「技術」状態のために同期が必要になる場合があります。これには、synchronized キーワードを使用できます。(アトミック変数を中継したり、DB シーケンスのようなアプリケーション外のものを使用して技術的な状態を共有したりすることもできます...)
連続する請求書番号を作成する場合 (シーケンスに穴がないようにする場合)、何らかの状態を共有する方法と、同期する方法が必要です...
仰るとおりです。
スレッドセーフなコンポーネントを設計する場合、同期は重要だと思いますが、通常、「ビジネスロジック」コードでは必要ありません。
共有状態を導入することでパフォーマンスを向上させることができますが、将来的にはアプリケーションのスケーラビリティが低下します。
同時設計が必要な場合は、たとえばアプリケーションサーバーを使用して、アプリケーション開発者に対して透過的に処理できます。