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

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

答え： 同じ不変フィールドからequals()とhashCode()の両方を実装する

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

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

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

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

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

答え： Optionalを返し呼出し側が不在時の方針を決める

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

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

答え： 共有可変状態を避け標準コレクターか結合則を満たすreduceを使う

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

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

答え： AtomicLongのincrementAndGet()で加算する

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

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

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

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

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

答え： finalフィールドかrecordを使い可変コレクションは防御的コピーする

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

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

答え： List<? super Integer>を引数の型にする

PECSはプロデューサーExtends, コンシューマーSuperです。Integerを書き込む消費側にはList<? super Integer>を使い、Integerまたはそのスーパータイプのリストを受け入れます。

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

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

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

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

答え： 複数リクエストが同じインスタンスを共有し利用者IDが混ざる

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

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

答え： 共通設定と環境別プロファイルを分け秘密情報は外部設定で渡す

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

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

答え： 自己呼出しはProxyを通らずBのトランザクション属性が効かない

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

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

答え： 未処理のRuntimeExceptionでロールバックし検査例外はrollbackForで指定する

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

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

答え： 短いDB更新で状態を記録しアウトボックス経由で非同期に連携する

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

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

答え： DTOへBeanバリデーション制約を付けController引数に@Validを指定する

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

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

答え： @ConfigurationPropertiesでまとめてバインドし制約で検証する

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

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

答え： 同じ表現を何度PUTしても最終状態が同じになるよう置換で更新する

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

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

答え： 202 Acceptedと状態確認用の位置情報または識別子を返す

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

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

答え： @RestControllerAdviceと@ExceptionHandlerで一元処理する

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

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

答え： 相関IDはServlet Filter、ハンドラ依存の処理はHandlerInterceptor

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

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

答え： Spring SecurityのCSRF保護を有効にしトークンを検証する

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

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

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

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

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

答え： 発行者の署名とiss・exp、API向けのaudや権限を検証する

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

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

答え： 相関ID・経路・結果・処理時間を構造化し機密はマスクする

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

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

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

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

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

答え： Serviceのトランザクション内で取得しAPI用DTOに変換して返す

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

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

答え： @Versionによる楽観ロックで競合を検出する

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

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

答え： 安定した一意な並び順と最後のキーを使うkeyset paginationにする

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

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

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

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

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

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

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

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

答え： Flyway等で順序付きマイグレーションを版管理し段階的に適用する

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

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

答え： @WebMvcTestとMockMvcを使い依存はテストダブルに置き換える

Web slice testはSpring MVC関連Beanへ範囲を絞り、MockMvcで実際のルーティング、変換、バリデーション、Filterやセキュリティ連携を確認できます。

PostgreSQL固有のSQLとマイグレーションをCIで検証したい。H2との差異による見逃しを減らす方法はどれですか？

答え： Testcontainersで対象バージョンのPostgreSQLを起動して試験する

実際のPostgreSQLコンテナをテストごとに再現可能な状態で使うと、方言、型、制約、インデックス、マイグレーションを本番に近い条件で検証できます。

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

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

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

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

答え： livenessとreadinessを分けreadinessだけで依存先を考慮する

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

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

答え： readinessを先に外しgraceful shutdownで処理中を完了させる

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

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

答え： タイムアウト・上限付き再試行・サーキットブレーカーを組み合わせる

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

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

答え： キー単位の単一再計算とTTLのジッターを組み合わせる

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

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

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

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

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

答え： ヒープ以外も見込んで余白を残しGC・RSS・OOMを監視する

JVMプロセスはヒープに加えてMetaspace、スレッドスタック、Directバッファ、ネイティブライブラリなどを使います。コンテナ上限から余白を引いてヒープを設計し、実測値で調整します。

多数のリクエストがブロッキングI/Oを待つJava 21のサーバで、仮想スレッドを使う主な狙いはどれですか？

答え： スレッドの待機コストを抑え同期コードのまま同時実行数を増やす

仮想スレッドはブロッキング中にCarrierスレッドを解放し、多数のI/O待ち処理を少数のOSスレッド上で扱いやすくします。処理単体の速度や外部資源の上限は変わりません。

仮想スレッドを導入したAPIが高負荷時にDB接続待ちで滞留した。適切な対応はどれですか？

答え： 接続プールとDB容量を実測し外部資源への同時実行数を制限する

仮想スレッドは待機中のスレッドコストを下げますが、DB接続や下流サービスの容量は増やしません。キュー長、接続使用率、待機時間を基にBulkheadとタイムアウトを設計します。

注文状態を有限種類に限定し、switchで未処理状態をコンパイル時に見つけやすくしたい。適切なJava設計はどれですか？

答え： sealed interfaceとrecordで状態を表し網羅的なswitchを使う

sealed型は実装可能な型を制限できます。許可された型をswitchで列挙すれば、新状態追加時に網羅性の不足を検出しやすくなります。

@Async付きメソッドを同じBean内からthis経由で呼んだところ同期実行された。主な原因と対策はどれですか？

答え： 自己呼出しはProxyを通らないため別Beanへ分離して呼ぶ

標準的なProxy方式では外部からProxyを通る呼出しにInterceptorが適用されます。同一インスタンス内のthis呼出しはProxyを迂回します。

Service層のpublicメソッド引数にもBeanバリデーションを適用したい。適切な方法はどれですか？

答え： メソッド検証を有効にしBeanと引数へ@Validatedと制約を付ける

Springのメソッドバリデーションを利用すると、Controller以外のBean境界でも引数と戻り値の制約を宣言できます。Proxy経由の呼出しで適用される点も考慮します。

参照専用のService処理へ@Transactional(readOnly = true)を付ける際の理解として適切なものはどれですか？

答え： 読取り専用の意図とヒントを伝えるが書込み禁止の保証ではない

readOnlyはトランザクション管理やORMへ意図を伝え、Flush動作などを最適化できる場合があります。強制力は利用するManagerやDBに依存するため、権限やテストも必要です。

在庫の同一行を短時間だけ直列更新し、競合時は待機または失敗させたい。適切なJPA手段はどれですか？

答え： PESSIMISTIC_WRITEロックと短いトランザクション、ロックタイムアウトを使う

悲観ロックはDBの行ロックを利用して競合更新を制御します。デッドロックや待機増加を避けるため、ロック順序、タイムアウト、トランザクション時間を管理します。

一覧APIがEntity全列と関連を読み込みメモリを圧迫している。必要な列だけ返すSpring Data JPA設計はどれですか？

答え： DTOまたはインタフェースプロジェクションをクエリ結果に定義する

プロジェクションはAPIで必要な列を直接選択し、Entity管理や不要な関連読込みを減らせます。更新用Entityと参照用ビューの責務も分離できます。

外部公開APIでエラー応答を標準化し、type、title、status、detailなどを返したい。Spring MVCで適切な型はどれですか？

答え： ProblemDetailでapplication/problem+jsonを返す

ProblemDetailはRFCのProblem Details形式を表し、標準フィールドと拡張プロパティを扱えます。内部情報を隠しつつ、利用者が機械処理できる契約を設計します。

APIのレスポンスDTOへ項目を追加する際、既存クライアントとの後方互換性を保つ基本方針はどれですか？

答え： 追加項目は任意とし未知項目を許容する仕様にする

Tolerantリーダーを前提とした追加的変更は、レスポンスAPIの代表的な互換拡張です。必須化や型・意味の変更はVersioningや移行期間を検討します。

Service内のDB更新がコミットした場合だけSpringのリスナーを実行したい。適切な機能はどれですか？

答え： @TransactionalEventListenerをAFTER_COMMITで使う

@TransactionalEventListenerはトランザクションPhaseへリスナーを結び付け、標準ではAFTER_COMMITです。ただし外部ブローカーへの確実な配送が必要ならアウトボックスなど永続化方式を検討します。

注文DB更新とメッセージブローカーへのイベント送信の間で障害が起きても、イベントを失わない設計はどれですか？

答え： 業務更新とアウトボックス行を同じトランザクションで保存し別途配信する

Transactionalアウトボックスは業務データと配送予定を原子的に永続化します。Publisherは未送信行を再試行し、コンシューマー側もイベントIDで冪等に処理します。

外部API呼出しにSpringのRestClientを使う際、接続不能や5xxを安全に扱う基本設計はどれですか？

答え： タイムアウトとステータス別の例外変換、冪等操作のみのリトライを設計する

外部呼出しは期限を設け、HTTPステータスと通信障害をドメインエラーへ変換します。リトライは回数・バックオフ・ジッターを制限し、非冪等操作には冪等性キーなどが必要です。

API利用者ごとの認可をServiceメソッドでも強制し、Controller以外からの呼出しも保護したい。適切な方法はどれですか？

答え： メソッドセキュリティを有効にし@PreAuthorizeと所有権チェックを適用する

認可はサーバー側の業務境界で実施し、認証コンテキストの主体と対象リソースの関係を確認します。URLセキュリティとメソッドセキュリティを防御in深さとして組み合わせます。

Spring Boot Actuatorを本番公開する際の適切な方針はどれですか？

答え： 必要なエンドポイントだけを公開し認証認可で保護する

ActuatorにはヘルスやMetricsなど運用上有用な情報がある一方、構成や内部状態を露出し得ます。公開範囲を最小化し、管理ネットワークや専用セキュリティチェーンで保護します。

MicrometerでHTTPリクエストメトリクスへ利用者IDをタグ追加したところ時系列数が急増した。適切な改善はどれですか？

答え： Tagは低カーディナリティに限定し利用者単位はログやトレースへ移す

高カーディナリティTagは監視バックエンドのメモリ、コスト、クエリ性能を悪化させます。メトリクスは集約軸、トレースと構造化ログは個別リクエスト調査という役割分担にします。

@Async処理へ移るとトレースIDがログから消えた。適切な対応はどれですか？

答え： TaskDecorator等でObservationコンテキストを非同期側へ伝播する

ThreadLocalベースのコンテキストはExecutorへ自動継承されない場合があります。Micrometer Observationと対応するコンテキストPropagationを設定し、タスク実行時にキャプチャ・リストアします。

Serviceのキャッシュ更新で、DBトランザクションがロールバックしたのにキャッシュだけ新値になった。適切な改善はどれですか？

答え： キャッシュ更新をコミット後に結び付けるかDB成功後に無効化する

キャッシュはDBトランザクションと同じ原子性を持たないことが多いため、コミット結果に合わせて更新または無効化します。失敗時の再試行と短いTTLも整合性戦略に含めます。

Spring Bootの統合テストで外部決済APIへの依存を切り離し、HTTP契約とタイムアウト処理を検証したい。適切な方法はどれですか？

答え： Mock HTTPサーバーで応答と遅延を制御し実際のクライアント設定で試験する

WireMockなどのMockサーバーを使うと、ネットワーク境界を保ちながらステータス、ヘッダー、JSON、遅延、切断を再現できます。単体テストのMockと少数の実接続テストを補完します。

Spring Bootアップグレード時に依存ライブラリのバージョンを個別指定して不整合が増えた。適切な依存管理はどれですか？

答え： Spring Boot BOMの管理バージョンを基準にし上書きは最小限にする

Spring Bootの依存関係管理は検証済みの組合せを提供します。セキュリティ対応などでオーバーライドする場合も、依存関係Treeを確認し、起動・統合・回帰テストを実施します。

金額CSVの文字列 "0.1" をdoubleへ変換してから new BigDecimal(value) に渡すと、想定しない小数桁が現れました。入力された十進数を正確に保持する方法はどれですか？

答え： 元の文字列をBigDecimalのコンストラクタへ渡す

doubleを経由すると、十進数の0.1が二進浮動小数点で近似されます。new BigDecimal("0.1") ならその近似を持ち込みません。入力の解析と、業務規則に基づく小数桁の丸めは別の処理として扱います。

料金をBigDecimalで扱い、new BigDecimal("2.0") と new BigDecimal("2.00") を同額と判定したい設計です。小数桁数の違いを無視した数値比較はどれですか？

答え： compareToの結果が0かを調べ、数値として比較する

BigDecimalのequalsは値とscaleの両方を比較するため、この例ではfalseです。compareToは数値の大小を比較し、同額なら0になります。金額全般の判定でdoubleへ変換すると、別の値が丸めで同一になるリスクがあります。

Arrays.asList("A", "B") の結果へaddするとUnsupportedOperationExceptionになりました。既存要素を引き継ぎ、要素数を増減できるリストにする方法はどれですか？

答え： 返されたリストからnew ArrayListを作成して追加する

Arrays.asListは配列に裏付けられた固定長リストを返し、要素の置換はできますが追加・削除はできません。new ArrayList<>(Arrays.asList("A", "B")) なら、要素をコピーした可変長リストを得られます。

内部のArrayListを Collections.unmodifiableList で包んで外部へ渡しています。後から内部リストへ追加した値まで外部に見えました。この挙動の説明として適切なのはどれですか？

答え： 更新禁止のビューであり、元リストへの変更は反映される

unmodifiableListは独立したスナップショットではなく、元リストを参照するビューです。返した参照からの変更は禁止しても、元リストを別の参照から変更できます。元の追加・削除を反映させたくない場合は、コピーを作ってから公開します。要素自体の変更を防ぐには別途設計が必要です。

変更されないListから作ったStreamでcountを呼んだ後、同じStreamで合計を求めると失敗しました。同じデータへ二つの終端操作を行う適切な方法はどれですか？

答え： 各終端操作の前に、元のListからStreamを作り直す

Streamは一度だけ処理するためのパイプラインで、終端操作後の再利用はできません。元のListが変わらない前提なら、操作ごとにlist.stream()を呼べます。closeや実行モードの切替は、消費状態を巻き戻しません。

キャッシュ検索がOptionalを返します。cached.orElse(loadFromDb()) ではキャッシュに値があってもDB検索が実行されました。値がない場合だけDB検索する修正はどれですか？

答え： orElseGetへDB検索のSupplierを渡し、必要時だけ呼ぶ

メソッドの引数は呼び出し前に評価されるので、orElseへ渡すloadFromDb()は必ず実行されます。cached.orElseGet(() -> loadFromDb()) はSupplierを渡し、Optionalが空の場合にだけ検索します。検索結果を先に計算してしまわないことが重要です。

Runnableの処理中にThread.sleepがInterruptedExceptionを投げました。停止要求として扱い、呼び出し側にも割り込み状態を残したい設計です。catch内で適切なのはどれですか？

答え： 現在のスレッドへinterruptを呼び、処理から戻る

sleepがInterruptedExceptionを投げる際、割り込み状態はクリアされます。ここでは Thread.currentThread().interrupt() で再設定してreturnします。割り込みを無視した継続は、タスク停止を妨げます。リソース解放はfinallyなどで行います。

同じNotifier型のメール用BeanとSMS用Beanがあります。注文Serviceにはメール用だけを注入し、他の注入先の既定選択は変えたくありません。意図を明示する方法はどれですか？

答え： コンストラクタ引数のQualifierでメール用候補を指定する

メール用Beanに対応するQualifierをコンストラクタ引数へ指定すれば、その注入箇所で候補を絞れます。Primaryは型で選ぶ際の既定候補を変えるため、他の注入先へ影響させないという要件とは異なります。

Spring Data JPAの一覧でPageを返していますが、総件数を数えるSQLが重くなっています。画面は「次があるか」だけ使い、総件数と総ページ数は不要です。適切な見直しはどれですか？

答え： Sliceを返す設計へ変え、総件数を取得する必要をなくす

Sliceは次のデータがあるかを表せる一方、Pageのような総件数を要求しません。この画面要件なら不要な件数集計を避けられます。ただし深いOFFSETのコストを自動的に解消するものではなく、取得SQLと実行計画は別途確認します。

有効期限判定でInstant.nowを直接呼び、期限の直前・直後をテストすると実行時刻次第で失敗します。OSの時計を変更せずに境界を再現する設計はどれですか？

答え： Clockを注入し、テストでは固定時刻のClockを使う

時刻取得を Instant.now(clock) にし、Clockを依存として渡すと、テストではClock.fixedで指定の瞬間を再現できます。本番では進む時計を使い、テストごとに期限直前・一致・直後を固定して判定規則を検証します。