Java面接50問速習：JVMからSpring Bootまで完全網羅

Java面接50問速習：JVMからSpring Bootまで完全網羅

背景紹介

正直に言うと、「八股文」という言葉を初めて聞いた時は抵抗がありました——こんな時代に暗記するなんて？でも、7〜8社の大手IT企業の面接を受けた後、完全に悟りました：八股文は暗記のためではなく、知識体系の骨格を構築するためのものです。私が実際の面接で聞かれた50の高頻度Java面接問題をまとめました。JVM、並行処理、Spring、MySQL、Redis、メッセージキュー、分散システムの7つのモジュールをカバーしています。新卒でも中途でも、これをマスターすれば少なくとも技術面接は通過できます。

一、JVM（8問）

1. JVMメモリモデルとは？

ヒープ（Young世代+Old世代）、メソッド領域/Metaspace、VMスタック、ネイティブメソッドスタック、プログラムカウンタ。ヒープはスレッド共有、スタックとカウンタはスレッド固有。面接官が最も追及する質問：なぜヒープをYoungとOldに分けるのか？ほとんどのオブジェクトは短命なので、Young世代ではコピー算法が効率的だからです。

2. GCアルゴリズムには何がある？

マークスイープ（断片化あり）、マークコンパクト（断片化なしだが遅い）、コピー算法（Young世代で使用、速いが空間を消費）、世代別収集（統合アプローチ）。必須のフォローアップ：CMSはマークスイープを使用、フローティングゴミと断片化の問題あり；G1はリージョンベースの混合回収で、予測可能な一時停止時間を実現。

3. クラスローディングメカニズムと親委譲モデル？

ロード→検証→準備→解決→初期化。親委譲：親クラスローダーに先にロードさせ、親ができない場合のみ自分でロード。利点：重複ロードとセキュリティ問題を回避。親委譲を破る例：SPIメカニズム（スレッドコンテキストクラスローダー）、Tomcat（webappごとに独立したクラスローダー）。

4. OOMが発生する状況は？トラブルシューティング方法は？

ヒープオーバーフロー（オブジェクト多すぎ）、Metaspaceオーバーフロー（動的生成クラス多すぎ）、スタックオーバーフロー（再帰が深すぎ）。トラブルシューティング：jmapでヒープメモリ確認、jstackでスレッドスタック確認、MATでダンプファイル分析。面接で本番OOMの対応方法を聞かれました——まず-XX:+HeapDumpOnOutOfMemoryErrorパラメータを追加し、問題発生時に分析可能なダンプを確保。

5. JVMチューニングパラメータには何がある？

-Xms/-Xmxでヒープサイズ、-XmnでYoung世代サイズ、-XX:SurvivorRatioでEden/Survivor比率、-XX:MetaspaceSizeでMetaspaceサイズ、-XX:+UseG1GCでガベージコレクタ選択。実践的なチューニング：-Xmsと-Xmxを同じ値に設定して動的拡張を回避、G1のMaxGCPauseMillisは200msに設定。

6. 強参照・軟参照・弱参照・幽霊参照の違い？

強参照は回収されない、軟参照はメモリ不足時に回収（キャッシュに適切）、弱参照はGCで回収（ThreadLocalのkey）、幽霊参照はGC活動の追跡のみ。この問題は簡単そうに見えるが、面接官はThreadLocalメモリリークについて追及——keyは弱参照で回収されるが、valueは強参照で残るため、使用後にremove()を呼ぶ必要がある。

7. JVMでのオブジェクト生成プロセス？

クラスロード確認→メモリ割り当て（ポインタバンプまたはフリーリスト）→ゼロ初期化→オブジェクトヘッダー設定→initメソッド実行。並行安全性はCASまたはTLABを使用。フォローアップ：メモリ内のオブジェクトレイアウト？オブジェクトヘッダー（Mark Word+型ポインタ）、インスタンスデータ、アライメントパディング。

8. ガベージコレクタの選び方？

単CPU小メモリはSerial、マルチCPUでスループット重視はParallel Scavenge+Parallel Old、低遅延はCMSまたはG1、大ヒープ+予測可能遅延はZGC。実践経験：JDK8はCMSまたはG1、JDK11+は直接G1、JDK15+はZGCを検討可能。

二、並行処理（10問）

9. synchronizedとReentrantLockの違い？

synchronizedはキーワード、ReentrantLockはAPI；synchronizedは自動的にロック解放、ReentrantLockは手動unlockが必要；ReentrantLockはフェアロック、割り込み可能、複数条件変数をサポート。面接で聞かれた：ReentrantLockが良い場面は？フェアキューイングが必要な場合、tryLockでデッドロック回避、複数Conditionが必要な場合。

10. volatileキーワードの役割？

可視性を保証（メインメモリにフラッシュ）と命令の並べ替えを禁止、ただし原子性は保証しない。メモリバリアで実装。古典的シナリオ：DCLシングルトンパターンでinstanceにvolatileを付け、初期化途中のオブジェクトが他のスレッドに見えるのを防止。

11. スレッドプールのコアパラメータと実行フロー？

corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory、rejectedExecutionHandler。実行フロー：コアスレッド→キュー→非コアスレッド→拒否ポリシー。4つの拒否ポリシー：AbortPolicy（例外スロー）、CallerRunsPolicy（呼び出し元実行）、DiscardPolicy（破棄）、DiscardOldestPolicy（最古破棄）。必須知識：スレッドプールパラメータの設定方法？CPU集約型はN+1、IO集約型は2Nまたは公式で計算。

12. AQSの原理？

コアはvolatile int stateとCLH双方向待機キュー。排他モード（ReentrantLock）はstateが0なら取得可能、1ならキューで待機；共有モード（Semaphore）はstateが残り許可数を表す。テンプレートメソッドパターン：サブクラスがtryAcquire/tryReleaseを実装。面接で簡単なAQSを手書きするよう求められました——AQSを継承してtryAcquireをオーバーライドするだけ。

13. ThreadLocalの原理とメモリリーク問題？

各ThreadオブジェクトにThreadLocalMapがあり、keyはThreadLocalの弱参照、valueは強参照。メモリリークの原因：ThreadLocalがGCされるとkeyがnullになるが、valueは残る。解決策：使用後にremove()を呼ぶ。フォローアップ：スレッドプールでThreadLocalを使う際の注意点？スレッド再利用によるデータ混入——必ずfinallyでremove。

14. CASとは？どんな問題がある？

Compare And Swap、楽観的ロックの実装。問題：ABA問題（AtomicStampedReferenceで解決）、スピンオーバーヘッド（激しい競争時のCPU空転）、1つの共有変数の原子性しか保証できない（AtomicReferenceで複数変数をラップ）。

15. Javaのロック分類？

悲観的/楽観的、フェア/アンフェア、排他/共有、再入可能/再入不可、スピン/ブロッキング。synchronizedは悲観的、アンフェア、排他、再入可能ロック。ReentrantLockはデフォルトでアンフェア、フェアに設定可能。

16. CountDownLatchとCyclicBarrierの違い？

CountDownLatchは使い捨て、N個のスレッド完了を待機；CyclicBarrierは再利用可能、N個のスレッドが互いに到着を待ってから続行。シナリオ：CountDownLatchはメインスレッドがサブスレッド完了を待つ場合、CyclicBarrierはマルチスレッドの分割計算後の集約に適している。

17. Fork/Joinフレームワーク？

分割統治+ワークスティーリングアルゴリズム。大きなタスクを小さなタスクに分割してfork、結果をjoinでマージ。ワークスティーリング：アイドルスレッドが他のスレッドのキュー末尾からタスクを盗んで実行。CPU集約型の再帰計算タスクに適している。

18. happen-before原則？

8つのルール：プログラム順序、volatile、ロック、推移性、スレッド開始、スレッド終了、スレッド割り込み、オブジェクト終了。「時間的に先に発生する」ではなく、「前の操作の結果が後の操作から可視である」ことを意味する。

三、Spring（8問）

19. Spring IOCの理解？

制御の反転——オブジェクトの生成と依存関係の管理をコンテナに委譲。実装方式：依存性注入（DI）、コンストラクタ注入、Setter注入、フィールド注入（@Autowired）を含む。Beanライフサイクル：インスタンス化→プロパティ代入→初期化→使用→破棄。面接官が好む質問：BeanPostProcessorとBeanFactoryPostProcessorの違い？前者はBeanインスタンスを処理、後者はBeanDefinitionを処理。

20. Spring AOPの実装原理？

JDK動的プロキシ（インターフェース）とCGLIB（クラス）。Springはデフォルトでインターフェースがある場合JDKプロキシ、ない場合CGLIB。SpringBoot 2.xはデフォルトで全てCGLIB。アドバイスタイプ：Before、After、AfterReturning、AfterThrowing、Around。面接で聞かれた：AOPが失敗するシナリオ？内部メソッド呼び出し（プロキシを経由しない）、privateメソッド、staticメソッド。

21. Springトランザクション伝播メカニズム？

REQUIRED（デフォルト、あれば参加なければ新規作成）、REQUIRES_NEW（常に新規作成、現在を一時停止）、NESTED（ネストされたトランザクション）、SUPPORTS、NOT_SUPPORTED、MANDATORY、NEVER。最もよく出題：REQUIRED vs REQUIRES_NEW——前者は内外同じトランザクションで一緒にロールバック、後者は内側が独立してロールバックし外側に影響しない。

22. Springは循環依存をどう解決する？

3レベルキャッシュ：singletonObjects（完全なBean）、earlySingletonObjects（早期参照）、singletonFactories（Beanファクトリ）。フロー：A作成→Bへの依存を発見→B作成→Aへの依存を発見→3レベルキャッシュからAの早期参照を取得→B完了→A完了。注意：コンストラクタ注入とプロトタイプスコープは解決不可。フォローアップ：なぜ2レベルではなく3レベルキャッシュが必要？AOPプロキシを処理し、早期参照と最終参照の整合性を保証するため。

23. @Autowiredと@Resourceの違い？

@Autowiredは型で注入（Spring）、@Resourceは名前で注入（JSR-250）。@Autowiredは@Qualifierと組み合わせて名前で、@Resourceのname属性で名前を指定。面接官が聞く：同じ型のBeanが複数ある場合は？@Primaryまたは@Qualifierを使用。

24. SpringBoot自動設定の原理？

@SpringBootApplicationに@EnableAutoConfigurationが含まれる→SpringFactoriesLoaderがMETA-INF/spring.factoriesの設定クラスをロード→@Conditional条件でフィルタリング→Beanを組み立て。SpringBoot 2.7+はMETA-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.importsを使用。

25. Springでのデザインパターンの応用？

Factory（BeanFactory）、Singleton（Beanのデフォルトスコープ）、Proxy（AOP）、Template Method（JdbcTemplate）、Observer（イベントメカニズム）、Adapter（HandlerAdapter）、Strategy（ResourceLoader）。この問題はSpringの理解の深さを示す。

26. SpringMVCのリクエスト処理フロー？

リクエスト→DispatcherServlet→HandlerMappingでHandler検索→HandlerAdapterで実行→Controller処理→ModelAndView返却→ViewResolverでビュー解決→レスポンス。フォローアップ：インターセプターとフィルターの違い？インターセプターはSpringのもの、フィルターはServletのもの；インターセプターはHandler情報にアクセス可能、フィルターは不可。

四、MySQL（8問）

27. MySQLインデックスのデータ構造？なぜB+木？

InnoDBはB+木を使用。理由：1）木が低い（3-4層で千万データを格納）、IOが少ない；2）葉ノードがリンクで接続、範囲クエリが高速；3）非葉はキーのみ格納、1ページにより多くのキーを格納可能。フォローアップ：クラスタインデックスvs非クラスタインデックス？クラスタインデックスの葉は行データ全体を格納（主キーインデックス）、非クラスタインデックスの葉は主キー値を格納（セカンダリインデックス）、非インデックス列の検索にはテーブルルックアップが必要。

28. トランザクションの隔離レベル？

Read Uncommitted（ダーティリード）、Read Committed（非再現リード）、Repeatable Read（ファントムリード、MySQLデフォルト）、Serializable。InnoDBはRRレベルでMVCC+ギャップロックにより大部分のファントムリードを解決。MVCC：各行に隠し列trx_idとroll_pointerがあり、読み取り操作はReadViewで可視性を判断。

29. MySQLロックメカニズム？

テーブルロック（オーバーヘッド小、並行性低）、行ロック（オーバーヘッド大、並行性高）、ギャップロック（インデックスギャップをロックしファントムリードを防止）、ネクストキーロック（行ロック+ギャップロック）。InnoDBの行ロックはインデックスに付与——インデックスを使用しないとテーブルロックに退化！必須知識：ロック状態の確認方法？show engine innodb statusまたはinformation_schema.INNODB_LOCKSをクエリ。

30. スロークエリの最適化方法？

1）EXPLAINで実行計画確認；2）インデックスが使用されているか確認；3）select *を回避；4）インデックス無効化を回避（関数、暗黙的変換、先頭%のLIKE、OR）；5）適切なインデックス構築（複合インデックスの最左前置）；6）ページネーション最適化（遅延結合）；7）データ量が大きい場合はシャーディングを検討。

31. 複合インデックスの最左前置原則？

インデックス(a,b,c)はa、a,b、a,b,cにマッチするが、b、c、b,cにはマッチしない。ただしMySQLのオプティマイザは順序を調整するため、WHERE b=1 AND a=2でもインデックスを使用可能。範囲クエリ後の列はインデックスを使用しない：WHERE a>1 AND b=2、aのみインデックス使用。

32. MySQLレプリケーションの原理？

マスタがbinlogに書き込み→スレーブのIOスレッドがbinlogを取得しrelay logに書き込み→スレーブのSQLスレッドがrelay logを実行。非同期レプリケーションはデータ損失の可能性あり、半同期レプリケーションは少なくとも1つのスレーブがbinlog受信を確認。フォローアップ：レプリケーション遅延の対処？自分のマスタから読み取り、強制的にマスタから読み取り、seconds_behind_masterを確認。

33. シャーディング戦略？

垂直分割（ビジネス別にデータベース分割）、水平分割（ルール別にテーブル分割）。シャードキーの選択：クエリ頻度の高いフィールド。ミドルウェア：ShardingSphere、MyCat。シャーディング後の問題：分散トランザクション、クロスシャードJOIN、グローバルID（Snowflakeアルゴリズム）、データ移行。

34. EXPLAINのtypeフィールドの意味？

良い順に：system>const>eq_ref>ref>range>index>ALL。少なくともrangeレベルに到達すべき、ALL（フルテーブルスキャン）は回避。ExtraのUsing indexはカバリングインデックス（良好）、Using filesortとUsing temporaryは最適化が必要。

五、Redis（6問）

35. Redisが速い理由？

1）純粋なインメモリ操作；2）シングルスレッドでコンテキストスイッチとロック競合を回避；3）IO多重化（epoll）；4）効率的なデータ構造。フォローアップ：Redis 6.0でマルチスレッドを導入した理由？ネットワークIOパフォーマンスの向上——コマンド実行はまだシングルスレッド。

36. Redisのデータ構造？

5つの基本型：String、List、Hash、Set、ZSet。基盤エンコーディング：StringはSDS、Listはquicklist、Hashはziplist/hashtable、Setはintset/hashtable、ZSetはziplist/skiplist+hashtable。面接官が好む質問：なぜ赤黒木ではなくスキップリスト？実装がシンプル、範囲クエリが便利、挿入は隣接ノードの調整のみ。

37. Redis永続化方式？

RDB（スナップショット、復旧は速いがデータ損失の可能性）とAOF（ログ追記、データは安全だがファイルが大きい）。ハイブリッド永続化：RDBでフル+AOFで増分。AOFの3つのfsync戦略：always（毎コマンド）、everysec（毎秒）、no（OS決定）。推奨：everysec。

38. Redisキャッシュのペネトレーション・ブレイクダウン・アバランシェ？

ペネトレーション（存在しないデータの検索）：ブルームフィルター、null値キャッシュ。ブレイクダウン（ホットキーの期限切れ）：ミューテックスロック、ホットキーの期限切れなし。アバランシェ（大量のキーが同時期限切れ）：ランダムな期限時間、マルチレベルキャッシュ、レート制限とデグラデーション。この3つはほぼ必出——完全なソリューションを説明できる必要がある。

39. Redisクラスタソリューション？

マスタスレーブレプリケーション（読み書き分離）、センチネル（自動フェイルオーバー）、Cluster（16384スロットのシャードストレージ）。Clusterアプローチ：クライアントがCRC16(key) % 16384でスロットを計算、各ノードが一部のスロットを担当。フォローアップ：クラスタは強整合性を保証できるか？できない、非同期レプリケーションでデータ損失の可能性あり。

40. Redis分散ロックの実装方法？

SET key value NX EX 30（アトミック操作）。valueにUUIDを使用し、他人のロックの誤削除を防止。ロック解放はLuaスクリプトで原子性を保証：valueが一致するか確認してから削除。Redissonフレームワークはウォッチドッグ自動延長を提供。フォローアップ：RedLockアルゴリズム？複数のRedisインスタンスで過半数がロック取得成功なら成功、ただし議論あり。

六、メッセージキュー（5問）

41. なぜメッセージキューを使う？

疎結合、非同期処理、ピークカッティング。欠点：システム複雑性の増加（重複消費、メッセージ損失、順序問題）、可用性の低下。面接官が聞く：メッセージの損失をどう防ぐ？プロデューサー確認+MQ永続化+コンシューマー手動ACK。

42. Kafkaアーキテクチャとコア概念？

Producer→Broker（Topic→Partition→Replica）→Consumer Group。Partitionは並行度の単位、同じConsumer Group内では1つのPartitionは1つのConsumerのみ消費可能。ISRメカニズム：Leaderが同期レプリカセットを維持、ISR内のレプリカのみが新Leaderになれる。

43. Kafkaはメッセージの順序をどう保証する？

同じPartition内のメッセージは順序付き。グローバルな順序を保証するには1つのPartitionのみ（推奨されない）。実際のアプローチ：同じビジネスキーを同じPartitionに送信。フォローアップ：Consumerリバランスによる重複消費の対処？冪等処理。

44. RocketMQとKafkaの違い？

RocketMQはトランザクションメッセージ、遅延メッセージ、メッセージバックトラックをサポート；Kafkaはスループットが高く、エコシステムが優れている。RocketMQはNameServer（ステートレス）、KafkaはZooKeeperを使用。選択：ログ収集にはKafka、ビジネスメッセージにはRocketMQ。

45. メッセージ蓄積の対処方法？

緊急時：Consumer数の増加（Partition数を超えないよう注意）、一時的なConsumer拡張。長期的：消費が遅い原因の調査、消費ロジックの最適化、Partitionの増加。本番で500万件の蓄積に遭遇したことがあります——原因はコンシューマー側のDBスロークエリでした。

七、分散システム（5問）

46. CAP定理とBASE理論？

CAP：一貫性、可用性、分断耐性の3つは同時に満たせない、ネットワーク分断は必然なのでCPかAPの二択。BASE：基本的に可用、ソフト状態、結果的整合性——CAPのAPの延長。ZooKeeperはCP（選挙中は不可用）、EurekaはAP（強整合性を求めない）。

47. 分散ロックの実装アプローチ？

Redis（SET NX EX）、ZooKeeper（一時順序ノード）、MySQL（一意インデックスまたはFOR UPDATE）。比較：Redisは高性能だが信頼性は平均的、ZKは信頼性が高いが低性能、MySQLは最もシンプルだが高並行には不適。実践的な推奨：Redis+Redisson。

48. 分散トランザクションソリューション？

2PC（強整合性だがブロッキング）、TCC（Try-Confirm-Cancel、ビジネス侵入大）、SAGA（長トランザクション分割+補償）、ローカルメッセージテーブル+MQ（結果的整合性）、Seataフレームワーク。よく聞かれる：プロジェクトでどのソリューションを使用？ほとんどのインターネットプロジェクトは結果的整合性で十分。

49. 分散ID生成アプローチ？

UUID（順序なし、長すぎ）、DB自動増分（パフォーマンスボトルネック）、セグメントモード（一度にバッチ取得）、Snowflakeアルゴリズム（タイムスタンプ+マシンID+シーケンス、トレンド増加）、Redis自動増分。Snowflakeの問題：時計の巻き戻り（数ビットを巻き戻り検出用に予約）。

50. サービスサーキットブレーカーとデグラデーションの違い？

サーキットブレーカーは呼び出し側が自分を保護（連続失敗後に切断、ヒューズのようなもの）、デグラデーションは非コア機能を能動的に放棄してコアを保護（デフォルト値またはフォールバックデータを返す）。SentinelとHystrixが両方サポート。3つのサーキットブレーカー状態：閉→開→半開（回復の試探）。

実問題まとめ

上記50問はByteDance、Alibaba、Meituan、Kuaishouなどの大手IT企業の面接で実際に聞かれた高頻度問題です。最もよく聞かれるTop 10：JVMメモリモデル、GCアルゴリズム、synchronizedとReentrantLock、スレッドプールパラメータ、AQS、Spring循環依存、MySQLインデックス、トランザクション隔離レベル、Redisキャッシュ3連、分散ロック。出現頻度の高い順に準備することをお勧めします。

心得とアドバイス

1. 暗記だけしない——原理を理解しないとフォローアップ質問に対応できない。面接官の「なぜ」一つで暗記回答者が篩い落とされる。

2. 知識グラフを構築——JVM→GC→チューニングは一つのチェーン、synchronized→ロックアップグレード→AQSは別のチェーン。繋げると記憶がより強固に。

3. プロジェクト経験と結びつける——各知識ポイントに実際のシナリオを準備。例えば「プロジェクトでOOMに遭遇し、jmapでThreadLocalのremove忘れによるメモリリークを発見した」など。

4. 適度にソースコードを読む——全てを読む必要はないが、AQSのacquire/release、SpringのgetBeanフロー、HashMapのputフローは追うことをお勧め。

5. モック面接——相手と交互に質問し合う。言えることと書けることは別物、流暢に表現できることはさらに別物。

FAQ

Q：どこまで暗記すべき？

A：少なくとも自分の言葉で完全に説明でき、キー用語を間違えず、1レベルのフォローアップに対応できること。例えばJVMメモリモデルを説明した後、面接官が「メソッド領域とMetaspaceの違いは？」と聞いたら答えられる必要がある。

Q：これだけの準備で十分？

A：いいえ。これらは基礎——プロジェクト経験、アルゴリズム、システム設計も必要。しかし基礎が不十分だと、他が良くても技術面接を通過できない。

Q：中途と新卒で重点は同じ？

A：新卒は基礎原理（JVM、並行処理、コレクション）重視、中途は実践経験（チューニング、トラブルシューティング、アーキテクチャ選定）重視。中途は必ずプロジェクトに結びつけて説明し、単なる暗記回答にしないこと。

Q：50問の準備にどれくらいかかる？

A：Javaの基礎があれば、集中して2-3週間。1日5-8問、各問題を理解+ノート作成+口頭説明可能に。量より深さを重視。