はじめに
Spring の Bean には、どのくらいの期間生きるのか を決める仕組みがあります。
それが Bean のスコープ（Scope） です。
「Singleton と Prototype の違いがよくわからない」
「Web アプリだと Request とか Session とか出てくるけど何が違うの？」
そんな疑問を持つ方も多いと思います。
この記事では、Bean のスコープを やさしく・実務で役立つ形 で整理していきます。
まずはコードを見て、そこから少しずつ理解していきましょう。
まずはコードを確認
@Service
@Scope("prototype")
public class GreetingService {
public String greet() {
return "Hello!";
}
}このコードでは、GreetingService が
prototype スコープ の Bean として登録されます。
コードのしくみを解説
Bean のスコープとは
一言でいうと、
Bean がどのタイミングで作られ、どのくらいの期間生きるのかを決める設定
です。
Spring では、用途に応じていくつかのスコープが用意されています。
代表的なスコープをやさしく整理
Singleton（デフォルト）
アプリケーション全体で 1 つだけ作られる Bean
- Spring Boot ではほとんどの Bean がこれ
- メモリ効率が良い
- 状態を持たせると危険（共有されるため）
実務では最もよく使われるスコープです。
Prototype
呼ばれるたびに新しいインスタンスが作られる Bean
- 毎回新しいオブジェクトが必要なときに使う
- ただし、DI された後のライフサイクルは Spring が管理しない
- 実務で使う場面は少なめ
Request（Web アプリ向け）
1 リクエストごとに新しい Bean が作られる
- Web アプリでよく使われる
- リクエスト単位で状態を持ちたいときに便利
Session（Web アプリ向け）
1 セッションごとに 1 つの Bean が作られる
- ログインユーザーごとの状態管理に使える
- ただし使いすぎるとセッション肥大化の原因になる
Application
ServletContext 単位で 1 つだけ作られる Bean
- Web アプリ全体で共有したい情報に使える
- 使う場面は限定的
あわせて知っておきたいポイント
Singleton は“共有される”ことを意識する
状態を持たせると、複数のリクエストから同時にアクセスされて
予期しない動作になることがあります。
Prototype は DI と相性が悪いことも
DI された時点で 1 回だけ生成されるため、
「毎回新しいインスタンスが欲しい」という用途には向かないことがあります。
Web スコープは Web アプリでのみ有効
Request や Session は Web アプリケーションでのみ使えます。
CLI やバッチでは利用できません。
使うときに気をつけたいこと
基本は Singleton
特別な理由がなければ Singleton で十分です。
状態を持たせない
特に Singleton では、
フィールドに値を保持しないようにするのが安全です。
スコープを変えるときは理由を明確に
Prototype や Request を使う場合は、
「なぜ Singleton ではダメなのか」を意識すると設計が安定します。
まとめ
Bean のスコープは、
Bean がどのくらいの期間生きるのか
を決める大切な仕組みです。
- Singleton → 基本はこれ
- Prototype → 毎回新しいインスタンス
- Request / Session → Web アプリ向け
難しく聞こえますが、
「どのタイミングで新しくなるのか」
を意識するだけで理解がぐっと進みます。
Bean のスコープは、最初は抽象的に感じるかもしれませんが、
実務で遭遇するトラブルの多くが“スコープの理解不足”から生まれます。
この記事が、あなたの開発を少しでも楽にできますように。
Bean さんって、生きてる時間がそれぞれ違うんだね。なんだか生き物みたいでかわいいなあ。
コメント