Spring の bean スコープとライフサイクルコールバックを説明してください。

Question

IT Interview Practice · Accepted Answer

**bean スコープ** は、コンテナがいくつのインスタンスを作成し、それらがどれだけ生存するかを制御します。**ライフサイクルコールバック** は、bean が構築された直後と破棄される直前にコードを実行させます。

## 実際に使うスコープ

- **singleton** (デフォルト): コンテナごとに *1 つ* の共有インスタンス。起動時に事前に生成されます。
- **prototype**: bean が要求/注入されるたびに *新しい* インスタンス。
- **request** / **session**: HTTP リクエストまたはセッションごとに 1 インスタンス (web アプリのみ)。

```java
@Service // singleton by default — one shared OrderService for the whole app
public class OrderService { }

@Component
@Scope("prototype") // fresh instance on every getBean/inject
public class ReportBuilder { }
```

**古典的な罠:** prototype を singleton に注入すること。singleton は *1 度* だけ配線されるため、単一の prototype インスタンスを永遠に保持します — "毎回新しい" という約束が破れます。`@Lookup`、`ObjectProvider<ReportBuilder>`、または scoped-proxy で修正します。

## ライフサイクルコールバック

```java
@Component
public class ConnectionPool {

@PostConstruct // runs after dependencies are injected, before use
    public void open() { /* open sockets, warm caches */ }

@PreDestroy // runs on graceful container shutdown (singletons only)
    public void close() { /* release resources */ }
}
```

重要: Spring は prototype bean に対して `@PreDestroy` を呼び出しません — それらを引き渡して追跡をやめるので、*あなた* がそれらのクリーンアップを担います。

## なぜ重要なのか

これは Spring を魔法として扱う人と、コンテナを理解している人を分けます。prototype を保持する singleton のバグは、微妙で実際の本番バグを引き起こすため、面接で好まれるシナリオです。singleton が **ステートレスかつスレッドセーフ** でなければならない (すべてのリクエストスレッドで共有される) と知っていることが、面接官が耳を傾ける実践的な要点です。

実際に使うスコープ

ライフサイクルコールバック

なぜ重要なのか

関連する質問