面接を受けていると、同じテーマが繰り返し出てくることに気づきますよね。Java/Spring 系のバックエンド面接でよく聞かれる質問をテーマ別にまとめてみました。実際に受けた質問38個をもとに、どう答えればよいかを一緒に整理していきます。 Java の基礎 Java の特徴 オブジェクト指向の3つの柱で答えるのが安全です。 カプセル化(Encapsulation) — データと振る舞いを一つにまとめ、外部には必要なものだけを公開します。 継承(Inheritance) — 親クラスの属性と振る舞いを子クラスが受け継ぎます。 ポリモーフィズム(Polymorphism) — 同じインターフェースで多様な実装を呼び出せます。 これに 抽象化(Abstraction) を加えて4つとして説明することもあります。さらに、JVM 上で動くため プラットフォーム独立(Write Once, Run Anywhere) であること、ガベージコレクションでメモリを自動管理することにも触れると良いです。 最近は面接で 最新の Java 機能もよく聞かれます。Java 21 (LTS) 以降の主要機能くらいは押さえておきましょう。 Record (Java 16+) — 不変データクラスを一行で宣言 Sealed Class (Java 17+) — 継承可能なクラスを明示的に制限 Pattern Matching (Java 21+) — switch と instanceof のパターンマッチング Virtual Threads (Java 21+) — Project Loom の成果。軽量スレッドで並行処理 クラスとオブジェクト クラス(Class) — オブジェクトを作るための 設計図。属性(フィールド)と振る舞い(メソッド)を定義します。 オブジェクト(Object) — クラスから作られた 実際にメモリに乗った実体。 たい焼きの型がクラスなら、その型で焼いたたい焼きの一つひとつがオブジェクトです。 データ型(プリミティブ vs 参照型) プリミティブ型(Primitive) — 値そのものをスタックに格納します。byte、short、int、long、float、double、char、boolean の8種類です。 参照型(Reference) — ヒープに格納されたオブジェクトの アドレスを持ちます。クラス、配列、インターフェースなどが参照型です。 int a = 10; // プリミティブ:値10そのものを格納 String s = "hello"; // 参照型:ヒープ上のオブジェクトのアドレスを格納 インスタンス化 クラスという設計図からオブジェクトを 実際にメモリ上に作る行為です。new キーワードを使います。 User user = new User(); // User クラスをインスタンス化 このとき作られた user をクラスの インスタンスと呼びます。オブジェクトとほぼ同じ意味ですが、「どのクラスのインスタンスか」を強調したいときに「インスタンス」という表現を使います。 インターフェース vs 抽象クラス 区分 インターフェース 抽象クラス 目的 実装の強制(契約) 共通機能 + 一部強制 多重継承 可能 不可(単一継承) フィールド public static final のみ あらゆる種類が可能 メソッド abstract + default + static abstract + 通常 使い時 「何ができるか」 「何であるか(is-a)」 インターフェースは「このクラスはこういうことができる」という 契約です。抽象クラスは共通実装を子に継承させつつ、特定のメソッドの実装を子に強制したいときに使います。 ジェネリクス(Generic)を使う理由 一言で言うと 型安全性 + コードの再利用です。 // ジェネリクスなし List list = new ArrayList(); list.add("hello"); String s = (String) list.get(0); // キャスト必要、実行時エラーのリスク // ジェネリクス使用 List&x3C;String> list = new ArrayList&x3C;>(); list.add("hello"); String s = list.get(0); // キャスト不要、コンパイル時に型チェック 実行時に発生し得る ClassCastException を コンパイル時に検出できるのが最大のメリットです。 コレクションフレームワーク 全体像 大きく3つのインターフェースに分かれます。 List — 順序あり、重複可(ArrayList、LinkedList) Set — 順序なし、重複排除(HashSet、TreeSet、LinkedHashSet) Map — キー-値形式(HashMap、TreeMap、LinkedHashMap) Map は Collection インターフェースを継承していませんが、コレクションフレームワークに含まれます。 Java 21 で Sequenced Collections が追加されました。SequencedCollection、SequencedSet、SequencedMap インターフェースが、先頭/末尾要素への一貫した API(getFirst()、getLast()、addFirst()、addLast()、reversed())を提供します。それ以前は LinkedList、LinkedHashSet、LinkedHashMap ごとに先頭/末尾へのアクセス方法がバラバラでした。 Array vs ArrayList 項目 Array ArrayList サイズ 固定 可変 型 プリミティブ/参照型ともに可 参照型のみ(ジェネリクス) 性能 高速(軽量) わずかなオーバーヘッド 機能 最小限 add、remove、contains など豊富 ArrayList も内部的には配列で実装されています。ただし 容量が足りなくなると、より大きな配列を新しく作ってコピーすることで可変サイズを実現しています。 キー-値 / 重複排除 キー-値:Map 系 → HashMap、TreeMap、LinkedHashMap 重複排除:Set 系 → HashSet、TreeSet、LinkedHashSet for-each で使える型 Iterable インターフェースを実装したすべての型です。配列も使えます。 public interface Iterable&x3C;T> { Iterator&x3C;T> iterator(); } Collection は Iterable を継承しているので、List、Set はそのまま使えます。Map は直接使えないので、entrySet()、keySet()、values() で変換して使います。 Spring &x26; DI/IoC DI と IoC IoC (Inversion of Control) — 制御の反転。オブジェクトの生成とライフサイクル管理を 開発者ではなくフレームワーク(コンテナ)が担当します。 DI (Dependency Injection) — 依存性注入。オブジェクトが必要な他のオブジェクトを 自分で作らずに外部から注入してもらう仕組み。IoC を実現する一つの手段です。 // DI なし public class OrderService { private UserRepository repo = new UserRepository(); // 強結合 } // DI 適用 public class OrderService { private final UserRepository repo; public OrderService(UserRepository repo) { // 外部から注入 this.repo = repo; } } メリットは 結合度の低下、テストしやすさ、コードの再利用性の向上です。 Spring Bean Scope singleton(デフォルト) — コンテナごとに一つのインスタンス prototype — リクエストごとに新しいインスタンス request — HTTP リクエストごとに一つ(Web 専用) session — HTTP セッションごとに一つ(Web 専用) application — ServletContext ごとに一つ(Web 専用) ほとんどのサービス Bean はステートレスに設計するので、singleton で十分です。 Spring のバージョン 2026年時点での実務標準は Spring Boot 3.x / Spring Framework 6.x です。主な変更点: Java 17 以上が必須(Spring Boot 3.2 から Java 21 が正式サポート、Virtual Threads が活用可能) javax.* → jakarta.* パッケージ変更(Jakarta EE 9 への移行)。最大の移行課題です。 GraalVM Native Image の正式サポート Observability の標準化(Micrometer + OpenTelemetry) Spring Boot 2.x を使っているプロジェクトは、この移行が面接でよく話題になります。 REST 標準アノテーション(HATEOAS / OpenAPI) 面接で「Spring の API アノテーションは標準に準拠していないが、標準化するにはどのライブラリを使うか?」という質問は、たいてい次のどちらかを聞いています。 HATEOAS (Hypermedia As The Engine Of Application State) — Roy Fielding が定義した真の REST の最終段階。Spring では Spring HATEOAS ライブラリを使います。 OpenAPI 3 / Swagger — API 仕様の標準。Spring では springdoc-openapi が事実上の標準(以前使われていた SpringFox は非推奨)。 HATEOAS はレスポンスに次のアクションへの リンク(href) を含めて、真の REST に近づけます。 { "id": 1, "name": "User", "_links": { "self": { "href": "/users/1" }, "orders": { "href": "/users/1/orders" } } } 実務では HATEOAS のフル適用は稀で、OpenAPI で API 仕様を標準化する方がはるかに一般的です。 HTTP &x26; REST HTTP HyperText Transfer Protocol — Web でクライアント-サーバーが通信するプロトコル ステートレス(Stateless) — 各リクエストは独立し、サーバーは過去のリクエストを記憶しません リクエスト-レスポンス構造:メソッド、URL、ヘッダー、ボディから成る デフォルトポート 80、HTTPS は 443 バージョンごとの主な違いも知っておきましょう。 バージョン 特徴 トランスポート HTTP/1.1 テキストベース、Keep-Alive TCP HTTP/2 バイナリ、多重化(Multiplexing)、ヘッダー圧縮(HPACK)、Server Push TCP + TLS HTTP/3 QUIC 上で動作、0-RTT 接続、TCP の Head-of-Line Blocking 解消 UDP + TLS 1.3 2026年時点では、主要 CDN や大規模サービスのほとんどが HTTP/3 を有効化しています。 HTTP メソッドの安全性/冪等性 メソッド Safe (安全) Idempotent (冪等) 用途 GET ○ ○ 取得 HEAD ○ ○ ヘッダーのみ取得 OPTIONS ○ ○ サポートメソッド確認 PUT × ○ 全更新/作成 DELETE × ○ 削除 POST × × 作成 PATCH × × 部分更新 Safe — サーバーの状態を変更しません(取得のみ) Idempotent — 何度リクエストしても結果が同じ HTTPS HTTP に TLS/SSL 暗号化を加えたプロトコルです。3つの保証を覚えておきましょう。 機密性(Confidentiality) — 通信データの暗号化 完全性(Integrity) — 途中でデータが改ざんされていないことを保証 認証(Authentication) — サーバーが本物であることを証明書で確認 ハンドシェイクは 非対称鍵でセッション鍵を安全に交換 → その後の通信は高速な対称鍵で進めます。 現在は TLS 1.3 が標準です。1-RTT ハンドシェイクで高速化され、脆弱とされた RSA 鍵交換、CBC、SHA-1 などのアルゴリズムは削除されました。TLS 1.0/1.1 はとっくに非推奨で、TLS 1.2 も段階的に整理される流れです。 RESTful API REST は REpresentational State Transfer の略です。主な原則は次の通りです。 リソース(Resource)を URL で識別 — /users/1 動作は HTTP メソッドで表現 — GET、POST、PUT、DELETE ステートレス性(Stateless) — サーバーはクライアントの状態を保存しません 表現(Representation) — JSON、XML などでリソースの状態を伝達 URL には 名詞だけ、動作は HTTP メソッドで。 悪い例: GET /getUser/1 良い例: GET /users/1 悪い例: POST /deleteUser/1 良い例: DELETE /users/1 OSI 7階層と HTTP 階層 名前 例 7 アプリケーション HTTP、FTP、SMTP、DNS 6 プレゼンテーション SSL/TLS、JPEG、ASCII 5 セッション NetBIOS、RPC 4 トランスポート TCP、UDP 3 ネットワーク IP、ICMP 2 データリンク Ethernet、MAC 1 物理 ケーブル、信号 HTTP は 7階層(アプリケーション)、TCP は4階層、IP は3階層で動作します。HTTPS の TLS は通常6階層(プレゼンテーション)に分類されます。 Web サーバー &x26; サーブレット Web サーバー vs WAS Web サーバー — 静的コンテンツ(HTML、CSS、画像)を処理。Nginx、Apache HTTPD。 WAS (Web Application Server) — 動的コンテンツの処理、ビジネスロジックの実行。Tomcat、Jetty。 実務では Web サーバー(Nginx)を前段、WAS(Tomcat)を後段に置く構成が多いです。静的リソースは Web サーバー、動的処理は WAS が担当することで負荷を分散します。 サーブレット(Servlet)の動作 クライアントからリクエストが来る サーブレットコンテナ(Tomcat など)がリクエストを受け取る URL マッピングで該当サーブレットを探す(なければインスタンス化) スレッドを一つ割り当てて service() → doGet() / doPost() を呼ぶ レスポンスを生成してクライアントに返す サーブレットは シングルトンで動作するので、複数のリクエストが同じインスタンスを共有します。そのため インスタンス変数に状態を保持するのは危険です。 Jakarta EE 9 以降、パッケージは javax.servlet → jakarta.servlet に変わり、Spring Boot 3.x もこれに追随しています。また Spring Boot 3.2 から Virtual Threads を有効にすれば、リクエストごとにスレッドを割り当てるモデルのコストが大きく下がります。非同期/ノンブロッキングが必要なら Spring WebFlux(リアクティブ)という選択肢もあります。 サーブレットフィルタ(Filter) サーブレットの 手前でリクエストとレスポンスを横取りするコンポーネントです。認証、ロギング、エンコーディング変換、CORS 処理などに使います。 クライアント → Filter 1 → Filter 2 → サーブレット → Filter 2 → Filter 1 → クライアント Spring の Interceptor と似ていますが、適用タイミングが違います。Filter は DispatcherServlet の前、Interceptor は DispatcherServlet の後・コントローラの前で動きます。 Cookie vs セッション 項目 Cookie セッション (Session) 保存場所 クライアント(ブラウザ) サーバー セキュリティ 比較的弱い 安全 容量 4KB 制限 サーバーメモリ次第 有効期限 設定した時間 ブラウザ終了時(または timeout) 機密情報はセッション、単純な識別子や自動ログイントークンは Cookie に保存するのが一般的です。自動ログインを Cookie に置く理由は、ブラウザを閉じても保持される必要があるためです。セッションはブラウザ終了/timeout で消えてしまいます。 Cookie のセキュリティ属性も押さえておきましょう。 HttpOnly — JavaScript からアクセス不可(XSS 対策) Secure — HTTPS でのみ送信 SameSite — Strict / Lax / None。CSRF 対策。Chrome のデフォルトは Lax が標準になりました。 Partitioned (CHIPS) — サードパーティ Cookie の分離、トラッキング防止 最近はセッションの代わりに JWT(JSON Web Token) によるステートレス認証もよく使われます。サーバーメモリを消費しないので水平スケールに有利ですが、トークンの失効(revoke)が難しいという欠点があります。そのため、短命の access token + 長命の refresh token を組み合わせて運用します。 セキュリティ SQL インジェクション対策 最も確実な方法は PreparedStatement(パラメータバインディング) です。 // 危険:文字列結合 String sql = "SELECT * FROM users WHERE id = '" + userId + "'"; // 安全:パラメータバインディング String sql = "SELECT * FROM users WHERE id = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, userId); 「MyBatis や JPA を使えば自動で防いでくれるのでは?」 — 部分的にはその通りですが、完全に安全とは言えません。 MyBatis の {} は PreparedStatement に変換され安全、${} は文字列置換で危険 JPA の JPQL は安全ですが、Native Query で文字列を結合すると同様に危険 結論:ORM を使っていても、動的に SQL の一部を文字列で組み立てるときは常に注意が必要です。 プロキシ vs ゲートウェイ プロキシ(Proxy) — クライアントとサーバーの間に立つ 仲介者。同一プロトコル内で単純に要求を転送します。 Forward Proxy — クライアント側(社内網 → 外部) Reverse Proxy — サーバー側(外部 → 内部サーバーへの分散、Nginx) ゲートウェイ(Gateway) — プロトコル変換、ルーティング、認証、ロギングなど 付加機能まで担います。API Gateway が代表的です。 要するに プロキシは単純な仲介、ゲートウェイはトラフィックの入口で多様なポリシーを適用します。 MSA 時代に入ってからは Service Mesh(Istio、Linkerd)もよく話題になります。サイドカープロキシ(Envoy など)を介して サービス間通信をインフラレベルで処理します。mTLS、トラフィック分散、可観測性といった横断的関心事をアプリケーションコードの外に出すのが要点です。 メッセージキュー &x26; キャッシュ RabbitMQ の特徴 AMQP(Advanced Message Queuing Protocol) ベース Producer → Exchange → Queue → Consumer 構造 メッセージの永続化に対応(ディスク保存) 柔軟なルーティング(Exchange タイプによる) 多様な言語クライアントをサポート RabbitMQ Exchange タイプ(キュー以外の方式) キューに直接積むのではなく、Exchange がルーティングルールに従ってキューに振り分けます。 Exchange タイプ 動作 Direct ルーティングキーが完全一致するキューへ Topic ルーティングキーのパターンマッチ(*、) Fanout バインドされた全てのキューにブロードキャスト Headers メッセージのヘッダーに基づくルーティング Topic Exchange が、よく言う「トピックに publish する」方式です。order.created、order.cancelled のようなパターンルーティングに便利です。 ちなみに RabbitMQ 4.x からは Streams という新しい永続ログ構造もサポートされ、Kafka のような 再処理・長期保持が必要なシナリオにも使えます。ただし大規模なイベントストリーミングはやはり Kafka が強く、RabbitMQ は 信頼性のあるワークキューとして採用されることが多いです。 Redis 以外のキャッシュ(インメモリキャッシュ) 「RAM キャッシュ」と聞かれたら、ローカルなインメモリキャッシュのことです。 Caffeine — Java で最もよく使われる高性能インメモリキャッシュ Ehcache — Java 界の老舗、分散キャッシュにも対応 Guava Cache — Caffeine の前身。今は Caffeine 推奨 Memcached — 分散インメモリキャッシュ(Redis よりシンプル) Redis は 別サーバー + ネットワーク経由、Caffeine は JVM 内部で動きます。同一マシン内で高速なキャッシュが必要なら Caffeine、複数サーバーで共有するなら Redis が向いています。 JavaScript Minify する理由 ファイルサイズの削減 → ダウンロード速度向上 ネットワーク費用の節約 パース時間の短縮 空白、改行、コメントを削除し、変数名を短くします。セキュリティが目的ではありません(難読化は別の概念です)。 最近のビルドはほぼ esbuild、swc、Rolldown などの Go/Rust 製ツールが処理しています。従来の Webpack/Babel に比べ 数十倍速い バンドル/トランスパイルが可能なので、Vite や Turbopack といった次世代バンドラーの標準になりました。 インライン vs 外部ファイル 項目 インライン (&x3C;script>...&x3C;/script>) 外部ファイル (&x3C;script src="...">) HTTP リクエスト 追加なし 追加リクエストが発生 キャッシュ 不可 ブラウザキャッシュ可 再利用 ページごとに重複 複数ページで共有 保守性 難しい 容易 初期描画 速くなることも 初回リクエストは遅い HTTP/1.1 時代は外部ファイルのリクエスト費用が重荷でしたが、HTTP/2 以降の多重化で外部ファイルを複数取得しても大きな損失はなくなりました。そのため モジュールを細かく外部ファイルに分割し、ファーストビューに必要な critical CSS/JS だけインライン化するのが推奨されます。 インラインスクリプトの配置 &x3C;head> — ページ描画前に実行、DOM にはアクセス不可 &x3C;body> の終わり — DOM ロード後に実行、一般的に推奨 &x3C;head> + defer/async — ダウンロードは並列、実行タイミングを制御 DOM を操作するコードなら &x3C;/body> 直前が安全です。または DOMContentLoaded イベントを使います。 最近は &x3C;head> に置いて defer または type="module" を付けるのがモダンなベストプラクティスです。どちらも HTML パースをブロックせず、DOM 準備後に順序通りに実行されます。 &x3C;!-- モダン推奨パターン --> &x3C;script type="module" src="/app.js">&x3C;/script> &x3C;script defer src="/legacy.js">&x3C;/script> 協業とコミュニケーション 意見が異なるときどう対応するか この種の質問は 態度と思考プロセスを見ています。模範解答は次の流れです。 相手の意見を最後まで聞く — 意図と根拠を正確に理解 共通の目標を確認 — 「お互いに X を望んでいるよね?」 データ/根拠ベースで議論 — 感情ではなく客観的な根拠 決まった結論には従う(Disagree and Commit) — 決定後は100%協力 核心は 「相手に勝つことではなく、より良い結果を出すこと」 という姿勢です。 まとめ 面接の質問は結局 「基本をどれだけ正確に理解しているか」 を見るための道具です。キーワードを並べるだけの答えより、なぜそうなのか + 実務でどう使うかを一緒に説明できるよう準備しておくのが良いです。 知らない質問が出たら、正直に「正確には分かりませんが、こういう文脈で耳にしたことはあります」と認めるのも大きな加点になります。知らないことを知ったかぶりするのが最も危険です。 People take different roads seeking fulfilment and happiness. Just because theyre not on your road doesn't mean they've gotten lost.— Dalai Lama

面接で受けた質問を改めて見返すと、わかっているつもりの概念ももう一度整理することになりますよね。トラフィック処理から並行性、キャッシュ、インデックス、データ構造まで一気にまとめて答えてみます。 トラフィックとパフォーマンス どの程度のトラフィックを扱っていましたか? サービス規模によりますが、1日平均で数十万リクエストからピーク時で数百RPSくらいの環境を基準に話すのがいいですよ。大事なのは絶対値より、そのトラフィック下でどんなボトルネックに当たり、どう解決したかです。 面接官が聞きたいのは「DBコネクションプールが足りなかったので増やしました」ではなく、「スロークエリログを確認してインデックスを追加し、それでも足りずキャッシュを導入しました」というような段階的なアプローチなんです。 大規模トラフィックを扱うために興味深かった記事や勉強した内容 代表的に挙げられる資料はこんなものがあります。 ウーアハン兄弟(韓国の大手フードデリバリー会社)技術ブログの大規模トラフィック処理事例 Netflix Tech Blogのレジリエンスパターン (Hystrix, Circuit Breaker) Martin FowlerのCQRS、Event Sourcingの記事 High Scalabilityサイトのアーキテクチャ事例 キーワードは水平スケーリング、非同期処理、キャッシュ階層の分離、悲観的・楽観的ロックのトレードオフあたりに整理できます。 並行処理と並列処理 WebFluxとExecutorServiceの比較 WebFluxはリアクティブストリームベースのノンブロッキングモデルです。少数のイベントループスレッドで多数のリクエストを処理しますね。一方ExecutorServiceはスレッドプールベースの明示的なタスクランナーです。作業単位を直接スレッドプールに渡す方式ですね。 区分 WebFlux ExecutorService モデル ノンブロッキング / イベントループ ブロッキング / スレッドプール 適した作業 I/Oバウンド、長い待ち CPUバウンド、明示的な非同期 学習コスト 高い 低い デバッグ スタックトレース追跡が難しい 直感的 WebFluxは全区間がノンブロッキングであってこそ効果が出ます。途中にブロッキングコードが混じると、かえって性能が落ちることもあります。 Virtual Threadはどこに入ってきますか? Java 21 LTSから正式リリースされたVirtual Thread(Project Loom) がこの構図を大きく変えました。ポイントは「従来の同期コードのまま書きながら、ノンブロッキング相当のスループットを出せる」という点です。 try (var executor = Executors.newVirtualThreadPerTaskExecutor()) { executor.submit(() -> userClient.findById(id)); } Virtual ThreadはOSスレッドに1:1で紐づかず、ブロッキング呼び出しが起きるとキャリアスレッドからいったん外れて再開します。だからI/O待ちの間はOSスレッドを占有しません。 区分 WebFlux Virtual Thread コードスタイル リアクティブチェーン(Mono/Flux) 普通の同期コード 学習コスト 高い ほとんどない デバッグ 難しい 通常のスタックトレース 成熟度 長く使われている 21〜25 LTSで急速に成熟 ただしVirtual Threadも万能ではありません。synchronizedブロックの中でブロッキングI/Oを呼ぶとキャリアスレッドがピン(pin)留めされて、仮想スレッドの利点が消えてしまいます。Java 24からこのピン問題はかなり緩和されましたが、ライブラリ互換性とThreadLocalの使い方は依然として点検が必要です。 最近は「新規プロジェクトでWebFluxを必ず選ぶべきか?」への答えが以前と違ってきています。単純なI/O多重化が目的なら、Virtual Threadのほうが素直な選択になることが多いです。 parallelStreamのスレッド設定だけ変えればいいんじゃないですか? parallelStream()は基本的に共用ForkJoinPool(commonPool) を使います。システムプロパティで並列度を調整することはできます。 System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "8"); 問題は共用プールがJVM全体で共有される点です。一箇所で重い処理を走らせると他にも影響します。なので隔離が必要なら別のForkJoinPoolを作って、その中で実行する方が安全です。 ForkJoinPool customPool = new ForkJoinPool(4); customPool.submit(() -> list.parallelStream().map(...).toList()).get(); parallelStream vs ExecutorService、どんなときに効率的ですか? 用途が違います。 parallelStream: データコレクションをCPUバウンドな演算で変換するときに有利。短く均質な作業が多いときに向いています。 ExecutorService: 作業単位が明確で、スケジューリング・結果収集・キャンセルを直接制御したいときに向いています。I/O作業や作業ごとの所要時間が変動する場合に適しています。 要するに、データ処理パイプラインならparallelStream、独立した非同期タスク実行ならExecutorServiceです。 parallelStream vs 通常のStream、どちらが速いですか? 通常のStreamはシングルスレッドなので、データが小さい・演算が軽い・順序が重要なときに速いです。並列化のオーバーヘッド(スレッド分配、結果のマージ)がないからですね。 parallelStreamは次の条件がすべて揃ったときだけ有利です。 データ量が十分大きい(通常は数万件以上) 演算コストが大きい(CPUバウンド) 状態共有や順序依存がない 分割可能なデータ構造(ArrayList、IntStream.rangeなど — LinkedListは非効率) 小さなコレクションにparallelStreamを使うと、かえって遅くなります。 ノンブロッキングI/O ノンブロッキングI/Oは常に良いですか? いいえ。ワークロードの性質によります。 I/O待ち時間が長く同時接続数が多いときは確かに有利ですが、CPUバウンドな処理が多ければ差がないか、むしろ損をすることもあります。 ノンブロッキングI/Oの性能上のデメリット コンテキストスイッチが減る代わりにコードの複雑度が増します。 コールバック、リアクティブチェーン、エラー伝播のすべてに気を配る必要があります。 ブロッキングコード1行で全体が止まる可能性があります。 イベントループスレッドが詰まると他のリクエストも一緒に止まります。 デバッグとスタックトレースが難しいです。 非同期境界を越えると呼び出しスタックが切れます。 CPUバウンドな処理には利点がありません。 スレッドを増やしてもコア数を超えて速くはなりません。 キャッシュ キャッシュの利用経験 代表的にはRedis、Caffeine、Ehcacheを使います。利用ケースはだいたいこんな感じです。 読み込み中心の照会APIのレスポンスキャッシュ 外部API呼び出し結果のキャッシュ セッション・認証トークンストア 分散ロックの実装 キャッシュはいつ更新されますか? 戦略によって変わります。 TTL満了: 一定時間で無効化。一番シンプル。 Write-Through: DB書き込みと同時にキャッシュも更新。 Write-Behind: キャッシュに先に書き、非同期でDBに反映。 Cache-Aside (Lazy Loading): 照会時にキャッシュミスならDBから読んで埋める。更新時にはキャッシュを無効化または更新。 イベントベース無効化: DB変更イベント(Kafka、CDC)からキャッシュを更新。 キャッシュとDBのデータ整合性が崩れる可能性 崩れることがあります。代表的なシナリオはこれです。 DB更新後とキャッシュ無効化のあいだの短い時間に、別のリクエストが古いデータを読んでキャッシュを再充填した場合 複数インスタンス環境で、片方がキャッシュを更新する前にもう片方が読んだ場合 トランザクションがロールバックされたのにキャッシュは既に更新されている場合 TTLの間にDBが変わった場合、古いデータがそのまま見え続ける 緩和策としては、DBトランザクションのコミット後にキャッシュを無効化する、分散ロックで同時更新を防ぐ、バージョンキーで古いキャッシュを無視するなどがあります。 JVMとモニタリング OOMが発生しないようにするには 事前予防の側面ではこういうことをします。 ヒープサイズとGCアルゴリズムをワークロードに合わせて設定 (-Xmx, -Xms, -XX:+UseG1GCなど) メモリリーク防止: 静的コレクションに無制限に積まない、ThreadLocalを片付ける、キャッシュにサイズ制限を置く 大容量データのストリーミング処理: ファイル・DB結果を一度にメモリに載せない コネクション・リソースリーク防止: try-with-resourcesを使う GCアルゴリズム選択もワークロードによります。 G1GC: 大半の一般サーバーワークロードのデフォルト。スループットとレイテンシのバランスが良い。 ZGC: Java 15からproduction-ready。数十GB〜TB級のヒープでもsub-millisecond pauseを目指します。Java 21でGenerational ZGC(-XX:+UseZGC -XX:+ZGenerational)が導入され、スループット面でも追いつきました。 Shenandoah: ZGCと似た低レイテンシ志向のOpenJDK GC。 Parallel GC: スループット重視でレイテンシは多少犠牲にできるバッチ処理向け。 レスポンスレイテンシが重要なトラフィックの多いサービスでは、G1 → Generational ZGCに移す事例が増えています。 発生したときの対応はこうです。 -XX:+HeapDumpOnOutOfMemoryErrorオプションでヒープダンプを自動保存 MAT(Memory Analyzer Tool) でリーク対象オブジェクトを分析 GCログでパターンを確認(継続的増加 → リーク、一時的急増 → リクエストパターン) 一時的にはヒープを増やし、根本的にはリーク箇所を修正 サーバーのモニタリングはどうしていましたか? 最近はOpenTelemetry(OTel) が事実上の標準になっています。メトリック・ログ・トレースの3つのシグナルを1つのSDK/プロトコル(OTLP)で送り、バックエンドは選んで使うという構造ですね。 階層別に整理するとこうです。 収集(SDK・エージェント): OpenTelemetry Java Agent / Micrometer Tracing メトリックバックエンド: Prometheus + Grafana、CloudWatch ログバックエンド: Loki、Elasticsearch、OpenSearch トレースバックエンド: Grafana Tempo、Jaeger 商用APM: DataDog、New Relic、Grafana Cloud(いずれもOTLP受信に対応) 韓国でよく使われるツール: Pinpoint、Scouterもまだ現役ですが、新規システムはOTelベースに寄っていく流れです アラート: Grafana Alert、PagerDuty、Slack連携 肝心なのはトラフィック・エラー率・レスポンスタイム・リソース使用率(USE/REDメトリクス) を一画面で見られるようにし、traceIdでログ・メトリック・トレースを一気に行き来できるようにつないでおくことです。 synchronizedとアトミック演算 synchronizedの説明 synchronizedはJavaのモニタロックベースの同期キーワードです。メソッドやブロックに付けると、同じモニターオブジェクトを取得したスレッドだけが入れます。 public synchronized void increment() { count++; } 内部的にはオブジェクトヘッダのMark Wordにロック情報が記録され、JVMは状況に応じてバイアスドロック → 軽量ロック → 重量ロックへ段階的に昇格させます。 synchronized使用時の問題点 パフォーマンスのオーバーヘッド: 競合が激しいとOSレベルのロック(重量ロック)に至り、コンテキストスイッチが頻発します。 デッドロックの危険: ロック取得順が絡まると止まります。 再入は可能だが割り込み不可: LockインターフェースはlockInterruptibly()を提供しますが、synchronizedはできません。 公平性(fairness)の制御不可: どのスレッドが先にロックを取るか保証がありません。 タイムアウト不可: 無限に待つ可能性があります。 代替としてReentrantLock、ReadWriteLock、StampedLockを使うと、より細かく制御できます。 AtomicIntegerを知っていますか? AtomicIntegerはCAS(Compare-And-Swap)演算を活用したロックフリー整数クラスです。内部的にはUnsafe.compareAndSwapInt(または最新版ではVarHandle)を呼び出します。 AtomicInteger counter = new AtomicInteger(0); counter.incrementAndGet(); ロックを取らずにCPUのアトミック命令1つで処理するため、軽量なカウンターに適しています。 AtomicIntegerを自分で実装するなら 基本のアイデアはCASループです。 public class MyAtomicInteger { private volatile int value; private static final VarHandle VALUE; static { try { VALUE = MethodHandles.lookup() .findVarHandle(MyAtomicInteger.class, "value", int.class); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public int incrementAndGet() { int prev, next; do { prev = value; next = prev + 1; } while (!VALUE.compareAndSet(this, prev, next)); return next; } } ポイントはvolatileで可視性を保証 + CASで原子性を保証 + 失敗時はリトライです。 AtomicIntegerはいつ使い、いつ使わない方がいいですか? 向いているケース: 単一変数のカウントやフラグ 競合が軽い環境 避けたほうがいいケース: 競合が非常に激しいとCASのリトライが急増し、かえって遅くなります。このときはLongAdderを使います。内部でセルを分散して競合を減らす作りです。JDK内部ではセルに@jdk.internal.vm.annotation.Contendedを付けてfalse sharing(同じキャッシュラインを共有することによる性能低下)を防いでいます。 複数変数の一貫性が必要なときはロックやトランザクションのほうが適切です。 データ構造: HashMap、HashSet HashSet、HashMapはいつ使いますか? 平均O(1)の参照・挿入が必要なときに使います。HashMapはキーバリューマップ、HashSetは重複なしの集合ですね。内部的にはHashSetはHashMapをラップしています。 向いていない場合はこういう状況です。 順序が必要: LinkedHashMap、LinkedHashSet ソートが必要: TreeMap、TreeSet(O(log n)) 並行性が必要: ConcurrentHashMap null禁止: Hashtable、ConcurrentHashMapはnull不可 HashSetの性能が思うように出ないケース hashCode()の分布が均等でないとき — ハッシュ衝突が増えてO(n)に近づきます。 equals()とhashCode()が一貫していないとき — 入れたオブジェクトを再度見つけられません。 可変オブジェクトをキーにしてフィールドが変わったとき — ハッシュ値がずれて検索失敗します。 初期容量が不足しているとき — リサイズ(rehash)が頻発します。 ロードファクタが高すぎるとき — 衝突が増えます。 Java 8以降は1バケットの衝突が一定数を超えるとツリー(Red-Black Tree) に変換されてO(log n)を保証しますが、根本的にはよいhashCodeを作るのが先決です。 ThreadLocal JavaでThreadLocalを使ったことがありますか? はい、使います。代表的なケースはこれです。 リクエストごとのコンテキスト保存: 認証情報、トランザクションID、MDC(ログコンテキスト) SimpleDateFormatのようなスレッドセーフでないオブジェクトの再利用 SpringのRequestContextHolder、TransactionSynchronizationManager も内部でThreadLocalを使っています 注意点は必ずremove()で片付けることです。スレッドプール環境ではスレッドが再利用されるため、ThreadLocalの値が次のリクエストまで残ってしまうとセキュリティ事故やメモリリークにつながりかねません。 MySQLインデックス MySQLインデックスは何で、いつ使いますか? インデックスはテーブルデータへのアクセス速度を上げるための別のデータ構造です。本の目次のように、目的の行を素早く見つけられるようにします。 使うとよい場面はこれです。 WHERE句に頻繁に登場するカラム JOINのキーカラム ORDER BY、GROUP BYのカラム カーディナリティが高いカラム(値の種類が多いカラム) MySQL 8.0以降は、インデックス自体のオプションも増えました。 Descending Index: 降順ソートをインデックス段階で処理 Invisible Index: オプティマイザから見えなくして、安全に影響度をテスト Functional Index: JSON_EXTRACT(...)やLOWER(col)のような式にインデックス可能 Multi-Valued Index (JSON配列): JSON配列の中の値をインデックス化 インデックスは多ければ多いほどいいですか? いいえ。インデックスは書き込みコストを増やします。 INSERT、UPDATE、DELETEのたびに全インデックスを更新する必要があります。ディスク容量も食いますし、オプティマイザが誤ったインデックスを選ぶこともあります。 原則は実際のクエリパターンに必要な分だけ最小限に作ることです。 インデックスのデータ構造、B+ツリー MySQL InnoDBはB+ツリーを使います。B+ツリーの特徴はこれです。 実データ(またはPK)はリーフノードのみに存在 リーフノードは双方向連結リストでつながっており、範囲検索が速い 平衡木なので全リーフへの深さが等しい ディスクI/Oの単位(ページ)に最適化されており、1回のI/Oで多くのキーを読める InnoDBのPKインデックスはクラスタ化インデックスで、リーフに実際の行が保存されます。セカンダリインデックスはリーフにPK値を保持し、そのPKで再びクラスタ化インデックスを辿ります(これをback to base、またはlookupと呼びます)。 charAtの型問題 charAtの戻り値の型と受け取る型が違うときに発生するエラーのケース String.charAt(int)はcharを返します。ただ、Javaではcharは符号なし16ビット整数のように扱われるため、intに自動昇格して意図せぬ結果になることがあります。 String s = "1"; int x = s.charAt(0); // 49 ('1'のASCII) int y = s.charAt(0) - '0'; // 1 s.charAt(0)をそのまま足すと、数字の1ではなく49が入ります。比較でもハマりやすいです。 char c = '1'; if (c == 1) { ... } // false (49 != 1) if (c == '1') { ... } // true もうひとつ大きな落とし穴が、Unicodeの補助文字(サロゲートペア) です。絵文字や一部のCJK文字はchar2つで表現されるため、charAt(i)一回では完全な文字を取れません。 String s = "𝕏"; // U+1D54F s.length(); // 2 s.charAt(0); // サロゲートの片方だけを返す s.codePointAt(0); // 119887、完全なコードポイント 文字単位で扱うなら、codePointAt、String.codePoints()、Character.toChars()のようなAPIを使う必要があります。 まとめ 面接の質問は答えを丸暗記するものではなく、実際の状況でどんなトレードオフがあるかを説明できるかが問われます。同じ質問でも、「なぜそう動くのか」と「いつ別の選択肢を取るか」まで答えられると深みが変わります。 今日整理した25個の質問のなかで曖昧だったものがあれば、コードで小さなサンプルを動かして確かめてみてくださいね。 Difficulties increase the nearer we get to the goal.— Johann Wolfgang von Goethe

起業の準備をしていると、「政府支援事業に一度でも採択されれば…」と考えがちですよね。でも実際の現場では、支援金を受け取ったのに事業をたたむケースが少なくありません。韓国のアクセラレーター「ExitUp」の崔（チェ）代表のお話をもとに整理してみます。 政府支援事業についての誤解 政府支援事業は「通ればラッキー、落ちても仕方ない」というものではありません。当然採択されるという前提で、しっかり準備しておく姿勢が大切です。 ただ、ここで重要なポイントがあります。政府支援事業に依存してはいけません。 黒字だから資金調達をせずに粘っていたら、コロナのような外部環境の変化で事業を閉じてしまう例もあるんです。 さらに覚えておきたいのは、政府支援事業に落ちた案件には、投資家も投資したがらないという点です。「申請していない」のと「申請して落ちた」のでは、まったく意味が違います。 ステージ別の資金調達手段 スタートアップの成長段階ごとに、出会う投資家のタイプが変わります。 ステージ 主な投資家 Seed ~ Pre-A エンジェル投資家、FFF、アクセラレーター Series A ~ B アクセラレーター、ベンチャーキャピタル Series C ~ Pre IPO ベンチャーキャピタル、特定金融会社、資産運用会社 FFFはFamily, Friends, Foolsの略です。家族や友人など、ごく近い人たちが初期資金を出してくれるケースを指します。 MVPとMBP、準備にかかる期間 投資を受けるために、最低限用意しておきたいものが2つあります。 MVP（Minimum Viable Product）: 実用最小限の製品、所要期間は3〜6ヶ月 MBP（Minimum Business Plan）: 最小限の事業計画、所要期間は3日〜1週間 MBPは短期間で書けますが、MVPはしっかり時間をかけて作る必要があります。 市場調査はどうやる？ 市場調査は、大げさに始める必要はありません。次の2つからスタートするだけでも十分です。 Google検索で市場規模を把握する 顧客層を設定する ふさわしい市場を選ぶのがカギ 事業計画書で一番難しいのは、「自分のサービスの市場ってどこ？」という問いです。カレンダーアプリを作ると仮定してみましょう。 オンラインカレンダー市場? ほとんど無料で使われているのに収益化できる? カレンダーアプリ市場? 生産性アプリ市場? オンライン広告市場? LINEやメルカリ、PayPayのようなサービスがBM（ビジネスモデル）と市場をどう定義しているかを調べると、ヒントが見えてきます。 集客市場 vs 収益市場 ユーザーを集める市場と実際に収益を生む市場は、別物であることも多いんです。LINEが分かりやすい例ですよね。メッセージアプリで人を集めて、広告やスタンプ、決済で稼ぐわけです。 プレゼンではこの部分をしっかり説明する必要があります。さらに理想を言えば、説明しなくても資料を見るだけで「どうやって人を集めて、どうやって稼ぐか」が伝わるように書くことです。 事業計画書作成のコツ 政府支援事業の事業計画書は、「指示通りに書くだけ」では落ちることがあります。指示以上の内容を盛り込んでこそ、プラス評価になるんです。 審査の段階によってアプローチも変わります。 初期創業パッケージ（初創）: 売上ベースでの市場検証が必要 予備創業パッケージ（予創）: 顧客アンケートだけでも合格できる 評価項目のなかでは、実現可能性と成長戦略の配点が大きいです。 審査員が必ずしもあなたのアイデアを正しく理解してくれるとは限りません。だからこそ、誰が見ても分かる書き方が重要なんです。 政府機関が見る成果指標 支援金を受け取った後、機関は企業がどれだけ成果を出したかを3つの観点で見ます。 売上 雇用 投資額 この指標を意識して事業を運営すると、次の支援や評価で有利になります。 投資交渉時の注意点 投資家と契約を結ぶときは、**毒条項（独毒条項、toxic clauses）**に気をつけましょう。一見お得に見える条件でも、後になって会社の首を絞めることがあるんです。契約書は必ず法律の専門家と一緒に確認してください。 参考になるサイトとして、韓国のAngel Loungeというプラットフォームもあります。エンジェル投資家とつないでくれるサービスです。 まとめ 政府支援事業と投資は創業者にとって重要な資源ですが、依存するものになってはいけません。結局大事なのは、自分のアイデアの価値を自ら証明することです。 政府支援事業は「当然採択される」つもりで準備する 集客市場と収益市場を分けて説明する 資料を見るだけでBMが伝わるように書く 売上・雇用・投資を継続的に管理する 完璧な計画書を待つより、今あるアイデアでMBPを書いてみることが、最初の一歩になります。 The way to get started is to quit talking and begin doing.— Walt Disney