Java・Spring Boot実務 問題集・練習問題クイズ

HashMapのキーに独自クラスを使うとき、equals()とhashCode()の実装として適切なものはどれですか？

答え： equals()で等しいオブジェクトは同じhashCode()を返すよう、同じ不変フィールドから両方を実装する

equals()で等しい二つのオブジェクトは同じhashCode()を返す必要があります。キーとして格納中に値が変わらないフィールドから両方を実装すると、正しいバケットから検索できます。

ファイルとJDBCリソースを例外発生時にも確実に閉じたい。Javaで最も適切な方法はどれですか？

答え： AutoCloseableなリソースをtry-with-resourcesで宣言する

try-with-resourcesはブロック終了時にAutoCloseableを逆順で閉じ、処理例外とclose例外が同時に起きた場合は後者をsuppressed exceptionとして保持します。

戻り値が存在しない可能性をOptionalで表現するサービスメソッドの設計として適切なものはどれですか？

答え： Optionalを戻り値に使い、呼出し側でorElseThrow()などにより不在時の方針を決める

Optionalを戻り値に使うと、不在の可能性をAPI契約として明示できます。呼出し側は例外、代替値、別処理など業務上の方針を選択します。

並列Streamで要素を集計するとき、安全で意図が明確な実装はどれですか？

答え： 副作用のある共有変数を避け、標準Collectorや結合則を満たすreduceを使う

並列Streamでは処理が分割・結合されるため、共有可変状態を避け、結合順が変わっても結果が安定する集約を使います。標準Collectorは用途に応じた並列集約を実装しています。

複数スレッドから共有カウンタを1ずつ増やし、更新の消失を防ぎたい。適切な方法はどれですか？

答え： AtomicLongのincrementAndGet()を使う

incrementAndGet()は読取り・加算・書込みを原子的に行います。volatileは可視性を提供しますが、count++という複合操作全体の原子性は保証しません。

CompletableFutureで外部APIを二つ並行呼出しし、両方の成功結果を結合したい。適切な方法はどれですか？

答え： 二つのFutureをthenCombine()で結合し、exceptionally()などで失敗方針を明示する

独立したFutureを先に開始してthenCombine()で結果を結合すれば並行性を保てます。外部I/Oではタイムアウト、例外変換、適切なExecutorも合わせて設計します。

注文確定後に値が変わってはいけないDTOを設計する。適切な方法はどれですか？

答え： finalフィールドまたはrecordを使い、可変コレクションは防御的コピーして公開する

不変オブジェクトでは構築後に観測可能な状態が変わらないようにします。参照自体がfinalでも参照先は変更できるため、可変コレクションのコピーや変更不能ビューが必要です。

List<Integer>の値を追加可能なメソッド引数として、ジェネリクスのPECS原則に沿う型はどれですか？

答え： List<? super Integer>

PECSはProducer Extends, Consumer Superです。Integerを書き込む消費側にはList<? super Integer>を使い、IntegerまたはそのスーパータイプのListを受け入れます。

SpringのサービスクラスへRepositoryを注入する方法として、テスト容易性と必須依存の明示に優れるものはどれですか？

答え： Repositoryを引数に取るコンストラクタインジェクション

コンストラクタインジェクションは必須依存を生成時に要求し、final化しやすく、Springコンテナを起動しない単体テストでもテストダブルを渡せます。

SpringのsingletonスコープのServiceへリクエスト固有の利用者IDをフィールド保存すると何が問題ですか？

答え： 複数リクエストが同じインスタンスを共有し、利用者IDが競合・漏えいする可能性がある

Springのsingleton Beanは通常アプリケーション内で共有されます。リクエスト固有状態はメソッド引数や適切なスコープで扱い、共有Serviceは原則としてステートレスにします。

開発・ステージング・本番で接続先を切り替えるSpring Boot設定として適切なものはどれですか？

答え： 共通設定と環境別Profile設定を分け、環境変数など外部設定で有効Profileと秘密情報を渡す

Spring Bootの外部化設定とProfileを使うと、同じ成果物へ環境別の非秘密設定や秘密管理基盤から値を注入できます。環境差分をコードから分離できます。

同じService内で@Transactional付きpublicメソッドAから、同じクラスの@Transactional付きメソッドBをthis経由で呼ぶ場合の注意点はどれですか？

答え： 自己呼出しは通常Spring Proxyを通らず、B側に指定した新しいトランザクション属性が適用されないことがある

Proxyベースの宣言的トランザクションでは、外部からProxyを通る呼出しがInterceptorの対象です。自己呼出しでREQUIRES_NEWなどを期待するなら、責務を別Beanへ分けるなど境界を明示します。

@TransactionalメソッドでRuntimeExceptionが発生した。標準的なロールバック動作として適切な説明はどれですか？

答え： 未処理のRuntimeExceptionでは通常ロールバックされ、検査例外は必要に応じrollbackForなどで方針を明示する

Springの標準ルールではRuntimeExceptionとErrorがロールバック対象です。検査例外や業務例外の扱いは要件に応じて宣言し、例外を握りつぶす場合はrollback-only設定なども検討します。

外部決済APIの呼出しを含む注文処理で、DBトランザクションを長時間保持しない設計はどれですか？

答え： 短いDB更新で状態を記録し、Outboxなどで非同期連携して結果を別トランザクションで反映する

外部I/OをDBトランザクションから分離し、状態遷移とイベントを原子的に記録すると、ロック時間を短縮できます。非同期側では冪等性、再試行、補償処理を設計します。

Spring MVCのリクエストDTOで、メール形式と必須項目を宣言的に検証したい。適切な方法はどれですか？

答え： DTOへBean Validation制約を付け、Controller引数へ@Validを指定する

@NotBlankや@Emailなどの制約と@Validを組み合わせると、Controller処理前に入力を検証できます。エラー応答形式は共通例外処理で統一します。

多数の関連設定値を型安全に扱い、起動時に必須値を検証したい。Spring Bootで適切な方法はどれですか？

答え： @ConfigurationPropertiesでまとまりとしてバインドし、Validation制約を適用する

@ConfigurationPropertiesはprefix配下の値を型付きオブジェクトへまとめてバインドできます。制約検証を組み合わせると、不正・不足設定で起動を失敗させられます。

PUT /users/123 の再試行を安全にするREST API設計として適切なものはどれですか？

答え： 同じ表現を複数回PUTしても最終状態が同じになるよう、対象を置換または決定的に更新する

PUTは同じ要求を繰り返しても意図した最終状態が変わらない冪等な意味を持たせます。作成副作用を重複させる処理には、別設計や冪等性キーを検討します。

非同期ジョブの作成要求を受け付け、処理はまだ完了していない。適切なHTTP応答はどれですか？

答え： 202 Acceptedと、状態確認用リソースのLocationまたは識別子を返す

202は要求を受理したが処理が未完了であることを表します。クライアントが進捗・結果・失敗を確認できるジョブリソースを併せて設計します。

複数Controllerで発生する業務例外を統一したJSONエラー形式へ変換したい。適切なSpring MVC機能はどれですか？

答え： @RestControllerAdviceと@ExceptionHandler

@RestControllerAdviceで例外処理を横断的に定義すると、例外種別からHTTPステータスと安全なエラー本文への変換を一元化できます。

HTTPリクエスト全体へ相関IDを付与する処理と、Controller呼出し前後の認可補助処理を分けたい。適切な使い分けはどれですか？

答え： 相関IDはServlet Filter、Handler情報が必要な処理はHandlerInterceptorを使う

FilterはServletチェーンで広くリクエスト・レスポンスを扱えます。InterceptorはSpring MVCのHandler選択後に動作し、Controllerやアノテーション情報を利用する処理に向きます。

Cookieベースのログインを使うWebアプリで、利用者の意図しない状態変更リクエストを防ぐ対策はどれですか？

答え： Spring SecurityのCSRF保護を有効にし、状態変更要求で正しいCSRFトークンを検証する

ブラウザは対象サイトのCookieを自動送信するため、攻撃サイトから状態変更を誘導され得ます。CSRFトークンは攻撃元が正しい値を付けられないことを利用して要求を検証します。

別オリジンのSPAからSpring Boot APIを呼び出す。許可するオリジンとメソッドを限定したい。適切な対応はどれですか？

答え： Spring MVCまたはSpring Securityで信頼済みオリジン・メソッド・ヘッダーを明示したCORS設定を行う

CORSではAPIが許可する呼出し元を狭く定義し、必要なメソッド・ヘッダー・認証情報の扱いを設定します。認証・認可とは別の境界として両方を適用します。

Spring Boot APIをOAuth 2.0 Resource Serverとして保護し、JWTアクセストークンを検証する際に必要な確認はどれですか？

答え： 信頼する発行者の署名、iss、exp、およびAPI向けaudや権限を検証する

JWTは内容を読めるだけでは正当性を証明できません。信頼済み鍵による署名と標準Claim、有効期限、対象Audience、必要Scope・Roleを検証します。

本番APIのリクエストログ設計として適切なものはどれですか？

答え： 相関ID、経路、結果、処理時間を構造化記録し、認証情報や機密本文はマスクまたは除外する

ログは検索・集計できる構造を持たせ、相関IDで処理を追跡します。一方でトークン、Cookie、パスワード、個人情報は最小化し、マスキングと保持期限を設けます。

一覧APIで関連Entityを遅延読込みした結果、1回の一覧SQLに続いて各行ごとのSQLが発行されている。適切な改善はどれですか？

答え： 必要な関連だけをfetch join、EntityGraph、DTO projectionなどで一括取得する

N+1問題は必要な画面・ユースケースごとに取得計画を定義して解消します。DTO projectionは不要列・関連を避けやすく、fetch join等は重複行やページングへの影響も確認します。

Controllerでトランザクション終了後に遅延関連へアクセスし、LazyInitializationExceptionが発生した。適切な設計はどれですか？

答え： Serviceのトランザクション内で必要データを取得し、API用DTOへ変換して返す

ユースケースに必要なデータはServiceの明示的なトランザクション境界内で取得し、外部契約用DTOへ写します。Web層で永続化Contextへ依存しない設計になります。

同じEntityを複数利用者が編集するとき、後勝ちで更新を失わないためのJPA機能はどれですか？

答え： @Versionによる楽観ロック

@Version列は更新条件に旧バージョンを含め、他者更新済みなら更新件数不一致として競合を検出します。利用者へ再読込みやマージを促します。

更新が続く巨大な注文表をページングし、次ページ取得時の重複・欠落と深いOFFSETのコストを抑えたい。適切な方法はどれですか？

答え： 安定した一意な並び順を定義し、最後に取得したキーを使うkeyset paginationを採用する

作成時刻とIDなど一意で安定した順序を使い、直前ページ末尾より後を検索すると、深いOFFSET走査を避けやすくなります。更新の扱いとスナップショット要件も明示します。

JPAで数万件を一括登録するとき、メモリ増加を抑えつつバッチ処理したい。適切な方法はどれですか？

答え： 適切なバッチサイズでpersistし、一定件数ごとにflush()とclear()を行う

JDBCバッチ設定と一定単位のflush/clearを組み合わせると、SQL往復とPersistence Contextの肥大化を抑えられます。ID生成方式によるバッチ可否も確認します。

MyBatisで利用者入力を検索条件へ渡す際、SQLインジェクションを防ぐ基本的な指定はどれですか？

答え： 値は#{value}でバインドし、動的な識別子は許可リストから選ぶ

#{}はPreparedStatementのパラメータとして値をバインドします。表名やORDER BY列などプレースホルダー化できない識別子は、利用者文字列を直接使わずサーバー側の許可リストへ対応付けます。

複数インスタンスで稼働するSpring BootアプリのDBスキーマ変更を安全に配布したい。適切な方法はどれですか？

答え： Flywayなどで順序付きMigrationを版管理し、後方互換な変更を段階的に適用する

Migrationを不変の履歴として版管理し、expand-and-contractなどで旧版・新版アプリが共存できる変更順にします。適用の単一実行と失敗時手順も定めます。

ControllerのURL、入力検証、JSON応答、セキュリティ設定を軽量にテストし、DBや全Beanは起動したくない。適切なテストはどれですか？

答え： @WebMvcTestとMockMvcを使い、Controllerの依存をテストダブルへ置き換える

Web slice testはSpring MVC関連Beanへ範囲を絞り、MockMvcで実際のルーティング、変換、Validation、FilterやSecurity連携を確認できます。

PostgreSQL固有のSQLとMigrationをCIで検証したい。H2との差異による見逃しを減らす方法はどれですか？

答え： Testcontainersで対象バージョンのPostgreSQLを起動して統合テストする

実際のPostgreSQLコンテナをテストごとに再現可能な状態で使うと、方言、型、制約、Index、Migrationを本番に近い条件で検証できます。

@Transactional付き統合テストが終了時にロールバックされる構成で、見逃しやすい問題はどれですか？

答え： flushやcommit時に初めて発生する制約違反やイベント処理

Persistence Context内ではSQLが遅延される場合があります。テスト中に明示flushして例外を確認し、commit後イベントが重要なら実トランザクション完了を含む別テストを用意します。

Kubernetes上のSpring Bootアプリで、プロセス生存確認とトラフィック受付可否を分けたい。適切な設計はどれですか？

答え： Actuatorのlivenessとreadinessを分け、readinessだけで依存先を考慮してServiceから外す

livenessは再起動で回復できるプロセス異常、readinessは現在トラフィックを処理できるかを表します。外部DB障害で全Podを再起動する連鎖を避けます。

ローリング更新時に処理中リクエストを途中切断しにくくするSpring Boot運用はどれですか？

答え： readinessを先に外し、graceful shutdownと十分な終了猶予で新規受付停止後に処理を完了する

終了対象をロードバランシングから外して新規流入を止め、graceful shutdownで処理中要求を猶予内に完了させます。KubernetesのpreStopやterminationGracePeriodとの時間関係も調整します。

外部APIが遅延・失敗するとき、呼出し元Spring Bootサービスへの障害連鎖を抑える設計はどれですか？

答え： 接続・応答タイムアウト、上限付き再試行、Circuit Breaker、隔離を組み合わせる

呼出し時間と同時実行数を制限し、一時障害だけをバックオフ付きで再試行します。連続失敗時はCircuit Breakerで早期失敗させ、資源枯渇と障害連鎖を防ぎます。

高負荷時に同じキャッシュキーが失効し、多数のリクエストが同時にDBへ到達する問題への対策はどれですか？

答え： キー単位の単一再計算、TTLのジッター、必要に応じ事前更新を組み合わせる

Cache stampedeでは、一つのリクエストだけが値を再生成し他は待つsingle-flightや、同時失効を避けるTTLジッターが有効です。古い値の短期提供も要件に応じ検討します。

メッセージブローカーから注文イベントが再配信されても、同じ注文を二重登録しないConsumer設計はどれですか？

答え： イベントIDに一意制約を設け、処理結果と受信済み記録を同じDBトランザクションで保存する

少なくとも一回配送では重複を前提にします。永続的な一意キーと業務更新を原子的に扱えば、再配信時に処理済みと判定して副作用を重複させません。

コンテナのメモリ上限内でSpring Bootアプリを安定稼働させるJVM設定・監視として適切なものはどれですか？

答え： Heap以外のメモリも見込み、上限に余白を残してHeapを設定し、GC・RSS・OOM Killを監視する

JVMプロセスはHeapに加えてMetaspace、Thread Stack、Direct Buffer、ネイティブライブラリなどを使います。コンテナ上限から余白を引いてHeapを設計し、実測値で調整します。