サーブレットコンテナは、「一般的に」、サーブレットの1つのインスタンスと、同じインスタンスの異なるスレッドを作成して、複数のリクエストを処理します。（これは非推奨のSingleThreadModelやその他の機能を使用して変更できることは知っていますが、これは通常の方法です）。
インスタンスを作成するよりもスレッドを作成する方が優れているため、この背後にある単純な理由はパフォーマンスの向上だと思いました。しかし、これが理由ではないようです。一方、インスタンスを作成することには、開発者がスレッドセーフについて心配する必要がないという利点はほとんどありません。
私は、スレッドセーフのトレードオフに関するこの決定の理由を理解しようとしています。
それはパフォーマンスについてです。状態がない場合、ロックや競合はありません。サーブレットは基本的な構成要素であり、状態に関する前提で構築することは、そのレベルでは適切ではありません。
サーブレットは、コンテナがこのリクエストを受け取ったという言い方にすぎません。これは、アプリケーションがサーブレットを使用して何かを行うチャンスです。どのようなステートフルネスが必要になるかについての仮定は、ある種のアプリケーションには良いかもしれませんし、他のアプリケーションには悪いかもしれないので、サーブレットはそれにパントします。一般的な設計原則が機能している場合、それは一般的に役立つほど単純なものを維持しています。
SingleThreadModelは、すべてのスレッドセーフの問題を解決するわけではないことに注意してください。たとえば、SingleThreadModelサーブレットが使用されている場合でも、セッション属性と静的変数には、複数のスレッドで同時に複数のリクエストからアクセスできます。開発者は、インスタンス変数の使用を回避したり、これらのリソースにアクセスするコードのブロックを同期したりするなど、このインターフェイスを実装する代わりに、これらの問題を解決するために他の手段をとることをお勧めします。
詳細については、このスレッドを参照してください。