企业官网建设流程全解析

先说结论：Java基础这一块，重点是“语法要扎实、集合要源码级理解、JVM和并发要有画面感”。很多干了三五年的同学回去翻八股文，担心的其实不是那些API记不住，而是底层原理说得不够透。这篇总结我会按自己带新人、复习面试、做项目踩坑的实际经验来梳理，把高频考点和平时容易忽略的细节放到一起讲，适合准备校招/社招面试的人，也适合刚学完Java语法想系统过一遍的人。

1. 基础语法与核心API：先过一遍真正重要的东西

1.1 数据类型、包装类与缓存机制

Java基础里最容易被问穿的就是基本类型和包装类。八种基本类型里，long和double是64位，其余按字节大小记就行：byte(1)、short(2)、int(4)、float(4)、char(2)、boolean(理论上1位但规范没严格定义)。实际开发中，我一般建议POJO属性用包装类，因为基本类型有默认值0，会让“未赋值”和“值为0”混在一起，尤其在数据库映射场景特别容易埋雷。

包装类有几个细节值得专门记：

• Integer默认缓存-128到127，这个范围内Integer a = 100; Integer b = 100; a == b是true，超出范围就是false。你用new Integer(100)则是每次新对象，==永远false。线上踩过的坑：从Redis取Integer做==比较，小值正常，大值偶尔出问题，排查半天才发现是缓存范围。
• equals和==的区别，面试必问，但真正重要的是理解：==比的是栈上的值，基本类型比数值，引用类型比地址；equals默认就是==，但String、Integer等重写成了内容比较。
• 浮点数不要用==比较，用BigDecimal。这个不是八股，是实际扣过钱的教训。

1.2 String、StringBuilder、StringBuffer到底怎么选

这三个天天用，但很多人没搞透。String是不可变的，每次拼接都会产生新对象，循环里用+拼接字符串是性能杀手。StringBuffer是JDK1.0就有的，方法加了synchronized，线程安全但慢；StringBuilder是JDK1.5加的，线程不安全但快。日常开发99%的场景用StringBuilder，只有多线程共享同一个可变字符串对象时才考虑StringBuffer。

但这里有个进阶点，面试官常追问：String s = "a" + "b"和String s = new String("a") + new String("b")有什么区别。前者是编译期常量折叠，直接变成"ab"；后者是运行时拼接，底层会new StringBuilder。还有字符串常量池，"a"字面量会进常量池，new String("a")会创建两个对象（如果常量池里没有"a"的话）。JDK7以后常量池挪到了堆里，这个演进也要知道。

字符串面试的终极问题往往是intern()方法的作用：把字符串对象的内容尝试放进常量池，如果池里有相同内容的字符串就返回池中的引用，没有则加入并返回引用。理解这个，再去看String s1 = new String("a").intern()这类题就不慌了。

1.3 数组、拷贝和边界问题

数组是对象，length是属性不是方法，Arrays工具类提供排序、二分查找、拷贝等方法。深浅拷贝这个问题热搜里也有人问，核心在于：基本类型数组的clone()是深拷贝，引用类型数组的clone()是浅拷贝——拷贝的是引用，不是对象本身。对象深度拷贝，正确姿势是实现Serializable后用序列化/反序列化，或者手动逐字段拷贝，别指望clone()接口，那个是浅拷贝且还要重写。

还有个日常高频数组坑：Arrays.asList()返回的List是定长的，不能add/remove，它底层是直接包装数组，改元素会同步到原数组。很多新人在这上面踩坑，一调用add直接抛UnsupportedOperationException，怀疑人生。

2. 面向对象设计：不是背定义，而是要理解设计动机

2.1 封装、继承、多态怎么讲才有深度

封装最好讲成“隐藏实现细节，暴露稳定接口”，因为这样可以让你改内部实现时不影响调用方。做SDK或者公共组件的时候最能体会这个价值，你把API设计好，内部怎么重构都不怕。

继承是is-a关系，但强调一点：继承是耦合度最高的关系之一，父类一改子类就受影响。Effective Java里第一条“优先使用组合而非继承”就是这个道理。面试被问“继承有什么缺点”时别愣住，要答出“破坏了封装性、子类与父类强耦合、不灵活”这些点。

多态是Java面试的重头戏，记住三个条件：继承、重写、父类引用指向子类对象。但更有价值的理解是：多态让代码面向抽象编程，依赖倒置原则的落地靠的就是它。实际项目里，接口加策略模式就是多态的典型应用，新增一种实现不用改调用方代码。

2.2 接口和抽象类的选择逻辑

抽象类是模板，接口是契约。从设计层面看，抽象类适合“多个类有公共代码且需要共享状态”的场景；接口适合“只关心能力不关心实现”的场景。Java 8以后接口可以有default方法，两者的界限被模糊了，但指导思想没变：能用接口就别用抽象类，接口更灵活，一个类可以实现多个接口但只能继承一个父类。

还有个常见考点：抽象类可以有构造函数，但不能直接实例化，构造函数是给子类super()调用的；接口没有构造函数。抽象类的方法可以是public、protected、default，接口的方法（除了static/default方法）默认是public abstract。

如果项目需要定义一组相关类的骨架流程，可以用模板方法模式配合抽象类：父类定好流程骨架，子类重写步骤方法。这个在框架源码里非常常见，比如Spring的AbstractApplicationContext内部就是这种思路。

2.3 异常体系与try-with-resources

异常分两类：受检异常（Checked Exception）和非受检异常（RuntimeException）。受检异常强制你try-catch或throws，比如IOException、SQLException；非受检异常可以不处理，比如NullPointerException、IndexOutOfBoundsException。实际工作的体会是：受检异常在业务代码里容易被滥用，很多人捕了异常打印一下就完事，等于没处理，反而掩盖问题。现代框架比如Spring，大量用非受检异常包装受检异常，就是为了让事务回滚更干脆。

try-with-resources是JDK7引入的，配合AutoCloseable接口，可以自动关资源。写文件、连数据库的时候，比手动finally里close干净太多，而且finally里close还有个经典坑：如果try块抛异常的同时finally里close也抛异常，会覆盖try的异常，排查起来非常痛苦。用try-with-resources就不会有这个叠加问题。

3. 集合框架：面试八股的重灾区，也是拉开差距的分水岭

3.1 ArrayList和LinkedList的底层差异

ArrayList底层是Object数组，默认容量10，扩容是oldCapacity + (oldCapacity >> 1)，也就是1.5倍。扩容会创建新数组并拷贝，所以如果预知数据量大，用带初始容量的构造方法new ArrayList<>(10000)能省不少性能。

LinkedList底层是双向链表，插入删除在已知节点的情况下确实是O(1)，但按索引访问是O(n)，需要从头或尾遍历。实际项目中LinkedList很少用，因为数组的内存连续性和缓存友好性优势太明显。面试被问“什么时候用LinkedList”，标准答案是“频繁头尾插入删除”，但我常年使用中，除非写队列或LRU，否则ArrayList始终是首选。

线程安全方面这俩都不安全，Vector因为所有方法加synchronized，性能差，基本被弃用。真正需要线程安全的List，用Collections.synchronizedList()包装，或者并发场景下用CopyOnWriteArrayList。

3.2 HashMap从JDK7到JDK8的关键改动

HashMap是Java基础里当之无愧的“题眼”。先说结构：数组加链表加红黑树。JDK8的改动重点：

• 链表长度超过8且数组长度大于等于64时，链表转红黑树；树节点少于6时退化为链表。为什么是8？官方注释说是泊松分布，理想情况下负载因子0.75，链表长度到8的概率低到千万分之一。
• 头插法改尾插法。JDK7头插法在并发扩容时会形成环形链表，导致get死循环；JDK8改为尾插法解决这个问题，但HashMap依然线程不安全，并发下会丢数据。
• hash方法做了优化：(h = key.hashCode()) ^ (h >>> 16)，让高位也参与低位运算，减少碰撞。

默认负载因子0.75是时间与空间权衡的结果，扩容阈值size >= 数组长度 * 0.75时扩为两倍。容量始终是2的n次方，这样(n - 1) & hash就能代替取模运算，速度更快且分布均匀。

还有个必考细节：HashMap允许key和value为null，hashtable不行；ConcurrentHashMap的key和value都不允许null。原因设计层面是这样：ConcurrentHashMap在多线程场景下，get返回null时无法判断是“不存在”还是“value本来就为null”，所以干脆禁止，避免二义性。

3.3 ConcurrentHashMap怎么做到线程安全

分段锁是JDK7的设计，锁的是Segment，默认16段，并发度16。JDK8放弃了分段锁，用CAS加synchronized锁住数组的每个bin（桶），锁粒度更细，并发度提升明显。

理解JDK8版的put流程很重要：计算hash定位桶；桶为空就用CAS插入；桶不为空就锁住这个桶（链表的头节点或树的根节点），再操作；链表长度达标就树化；最后检查扩容。这个设计好在锁竞争只发生在同一个桶上，不同桶互不影响，实际并发性能很高。

关于size的计算，JDK8用sumCount和一个volatile变量baseCount组合，尽量避免全局锁。面试被问就说：维护一个CounterCell数组减少竞争，最终size是baseCount加CounterCell的和，允许一定程度的近似值。

3.4 集合的fail-fast机制

AQS热搜词也在里面，后面并发部分会讲。这里先提醒：ArrayList/HashMap迭代时如果被并发修改（不是通过迭代器自己的remove），会抛ConcurrentModificationException。原理是迭代器内部维护modCount，每次next都检查是否和预期值一致。注意fail-fast是及时报错机制，不是保证正确性，所以不要指望用它来做并发控制。

4. JVM内存与类加载：基础中的硬核部分

4.1 运行时数据区到底有哪些，各自的角色

JVM内存是面试必考，JDK8以后方法区变成了元空间，这个是最大的变化。运行时数据区分成线程私有和线程共享两大类：

线程私有的有程序计数器、虚拟机栈、本地方法栈。程序计数器记录当前线程执行的字节码行号，是唯一不会OOM的区域。虚拟机栈存储栈帧，每个方法调用对应入栈出栈，栈帧里含局部变量表、操作数栈、动态链接、方法返回地址。局部变量表在编译期就确定了大小，所以栈深度是固定的上限，递归过深就StackOverflowError。

线程共享的有堆和方法区。堆是对象实例的主要存储区，GC的主要发生地，分新生代（Eden、两个Survivor区）和老年代。元空间（Metaspace）替代了永久代，使用的是本地内存，默认无上限，但可以设置-XX:MetaspaceSize控制初始值。常量池在JDK7之后移到堆里，字符串常量池也是堆的一部分。

4.2 ClassLoader和双亲委派模型

类加载分三步：加载、链接（验证、准备、解析）、初始化。加载阶段通过类的全限定名获取字节流，然后在内存中生成Class对象。

双亲委派模型是重点：当一个类加载器收到加载请求时，先委派给父类加载器，父类再往上委派，到顶层Bootstrap ClassLoader为止，父类能加载就用父类的，加载不了才自己加载。这样做的核心目的是防止核心API被篡改，保证核心类库的类不会被自定义类加载器重复加载。

比如你自己写一个java.lang.String，在应用启动时类加载器会把请求委派到Bootstrap，加载的是JDK自带的String，你的类根本没机会被加载。Tomcat打破双亲委派是因为需要每个Web应用有独立的类隔离，不然不同的lib版本就冲突了。

4.3 GC基础：垃圾对象怎么判断、主流回收器

判定垃圾对象有两种方式：引用计数法和可达性分析。引用计数法有循环引用问题，所以主流JVM用可达性分析，从GC Roots出发向下遍历，不可达的对象就是可回收的。GC Roots包括：栈帧中的局部变量引用、静态变量、JNI引用、活跃线程等。

引用类型除了强引用还有软引用、弱引用、虚引用。软引用在内存不足时回收，适合做缓存；弱引用每次GC都回收；虚引用主要用于跟踪对象回收，配合ReferenceQueue使用。

垃圾收集器这块，面试主要问CMS和G1。CMS是标记-清除，目标是低停顿，缺点是会产生内存碎片，且并发阶段占用CPU资源。G1把堆分成Region，维护优先列表，优先回收垃圾最多的Region，可以预测停顿时间，JDK8之后慢慢替代CMS，JDK9之后G1成为默认。ZGC追求的是超大堆低延迟，目前JDK17之后的版本用得越来越多。

5. 并发编程：面试区分度的核心战场

5.1 volatile能保证什么，不能保证什么

volatile是Java基础里最容易被误解的关键字。它能保证两点：可见性和有序性（禁重排序），但不保证原子性。可见性，就是线程修改了volatile变量，其他线程能立即看到最新值。原理是写volatile变量时会强制把工作内存中改动刷新到主内存，并让其他CPU核心的缓存行失效（缓存一致性协议，x86上是MESI）。

为什么不能保证原子性？因为像count++这种操作是“读取-修改-写入”三步，volatile只能保证每次读取是最新值，但两个线程同时读到0，同时加1，同时写回，就会丢更新。所以计数场景还是需要AtomicInteger或synchronized。

有序性涉及指令重排序和内存屏障，单线程执行结果不变的前提下CPU和编译器会调整指令顺序。volatile写会在前面插入StoreStore屏障，后面插入StoreLoad屏障，防止重排序跨越volatile边界。单例模式的双重检查锁（DCL）之所以要加volatile，就是防止“new对象”过程中的重排序导致返回了一个未初始化完成的实例。

5.2 synchronized的锁升级过程

synchronized在JDK6之后有锁升级机制：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁。偏向锁是同一个线程反复进入同步块时，省去CAS开销；一旦有竞争就升级为轻量级锁，通过CAS自旋抢锁；自旋超过阈值或竞争加剧就升级为重量级锁，即操作系统级的互斥量，这时涉及用户态内核态切换，性能开销大。

JDK15开始偏向锁被废弃标记，JDK18默认关闭偏向锁，因为偏向锁引入的复杂度和维护成本已经大于收益，尤其是在现代应用中大量线程竞争的场景。面试答的时候提一嘴这个演进，说明你是关注新版本的。

其实synchronized加锁的本质是对象头里的Mark Word，里面有锁标志位和持有锁的线程ID等信息。这也是很多人忽略的点：任何对象都可以是锁，就是因为每个对象头里都有Mark Word。

5.3 AQS到底是什么，为什么Lock基于它能高效

AQS（AbstractQueuedSynchronizer）是JUC的基石，ReentrantLock、CountDownLatch、Semaphore、ReadWriteLock都基于它。很多人在面试时听到AQS就头皮发麻，其实核心就三个东西：

• 一个volatile int成员变量state，表示同步状态；
• 一个CLH变体队列（先进先出的双向队列），保存等待的线程节点；
• 基于CAS操作state来获取和释放锁。

拿ReentrantLock加锁举例：线程CAS把state从0改成1，成功就获得锁；失败就生成Node节点加入等待队列，通过LockSupport.park阻塞自己。可重入的实现就是同一个线程再次进来时state加1，释放时减到0才真正释放锁。

理解AQS之后，很多并发工具的本质就通了。Semaphore就是state表示剩余许可数量，CountDownLatch就是state表示还需要等待几个事件。所以我建议学习AQS不要死记源码，先去理解state和等待队列这两个核心，再去看源码就顺了。

5.4 保证数据一致性的几种手段

热搜里有“Java怎么保证数据一致性”，这个问题从基础层面回答的话分几档：

• 单线程内：不需要额外机制。
• 多线程共享变量：用volatile保证可见性，synchronized/Lock保证原子性。
• CAS无锁方案：Atomic类。
• 线程封闭：StackLocal（ThreadLocal）每个线程有独立副本，通过空间换时间避免竞争。
• 分布式场景：那就要靠数据库锁、Redis分布式锁、版本号乐观锁这些了。

面试时最好说清楚层次。数据一致性不是单点问题，从JVM内存模型到数据库隔离级别再到分布式事务，每一层都有对应手段，关键是识别并发问题的场景。

6. 开发中的高频坑点与面试实操经验

6.1 JDK安装与环境变量配置

这个热搜出现频率很高，简单说下最稳妥的配置方法：JDK安装后，需要配置JAVA_HOME、PATH、CLASSPATH三个变量。JAVA_HOME指向JDK安装根目录，PATH里加%JAVA_HOME%\bin（Windows）或$JAVA_HOME/bin（Linux/macOS），CLASSPATH一般设.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar（Windows），但JDK9以后模块化后classpath不再是必需项了。

验证是否成功：命令行执行java -version和javac -version。如果java有输出但javac提示找不到命令，基本就是PATH没配好或者配完没重开终端。另外，一定要确认安装的是JDK不是JRE，很多初学者装了JRE后发现不能编译代码，就是因为没有javac。

一个容易被忽略的点：新版JDK可能自带了旧版本，比如Windows下装了多个JDK，需要确保PATH顺序，把想要的版本放在前面。Linux下可以用update-alternatives --config java来切换版本。

6.2 源发行版17需要目标发行版17的编译错误

热搜里这句话很真实，我经常在社区看到新手问。报错原文大概是“警告: 源发行版 17 需要目标发行版 17”，或者“错误: 不支持发行版本 17”。本质上是Maven或者IDE里的编译级别和当前JDK版本不匹配。

常见的两种场景：

• IDEA里项目SDK选了JDK17，但Project Settings里Java Compiler的Target bytecode version还是1.8，导致javac尝试用17的源码特性编译到1.8的字节码，结果不支持。
• Maven项目里pom.xml指定了maven-compiler-plugin的source和target为1.8，但本地JDK已经到17，编译时也会警告或报错。

解决办法：统一三处配置——Project Structure里的SDK、Java Compiler的bytecode version、pom.xml里的<maven.compiler.source>和<maven.compiler.target>，或者用<java.version>属性统一定。最简单的方式是在pom.xml里加properties：

<properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties>

如果只是想消除警告，设置Java Compiler的-parameters加上--release 17也行，--release比source/target更严格，会同时检查API是否用了新版本特性。

6.3 POI操作Word能生成图表吗

热搜里有“java poi word能生成图表吗”，这个是我实际做过的场景。答案是：能，但不能像Excel那样直接创建Chart对象嵌入。POI操作Word图表，通常做法有两种：

• 用XWPFChart或手动拼Document XML。你不能直接调一个API生成柱状图，要操作的是word/drawings/chart1.xml，创建xwpfChart对象并把CategoryAxis和ValueAxis的数据填进去。
• 更务实的做法：后端用POI生成基础Word文档，图表部分用图片代替。先生成ECharts图片或Java绘图库（jfreechart）生成图表图片，再用XWPFRun.addPicture()插入文档。

为什么推荐用图片方案？因为POI直接操作图表的API要写的代码量很大，而且对模板的兼容性要求高，Word里图表本质是internal references，如果模板变了很容易出问题。图片方案简单稳定，视觉效果也完全可接受，图表本身的交互性在Word文档里反正也用不上。

6.4 Java动态代理与InvocationHandler

java.lang.reflect.InvocationHandler配合Proxy可以实现动态代理，这是Spring AOP的底层基础。核心步骤就三步：

// 1. 定义接口 public interface UserService { void addUser(String name); } // 2. 实现InvocationHandler public class LogHandler implements InvocationHandler { private final Object target; public LogHandler(Object target) { this.target = target; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { System.out.println("before: " + method.getName()); Object result = method.invoke(target, args); System.out.println("after: " + method.getName()); return result; } } // 3. 创建代理对象 UserService userService = new UserServiceImpl(); UserService proxy = (UserService) Proxy.newProxyInstance( userService.getClass().getClassLoader(), userService.getClass().getInterfaces(), new LogHandler(userService) ); proxy.addUser("zhangsan");

基于接口的动态代理底层是在运行时生成新的字节码类，继承Proxy并实现传入的接口。面试追问“如果目标类没有接口怎么办”，那就要答CGLIB——它通过生成目标类的子类来实现代理，所以被代理的类和方法不能是final的。Spring里默认是JDK代理，如果没有接口会自动切到CGLIB。

6.5 Java对象深度拷贝的正确姿势

深度拷贝的三种主流方案对比一下：

• 重写clone()并深拷贝所有引用字段：只适用于字段少、结构简单的场景，字段一变就漏。
• 序列化方式：对象实现Serializable，通过ObjectOutputStream写到字节数组再读回来。代码量小，通用性强，但性能一般，且对象里所有字段都必须可序列化。
• MapStruct、Spring BeanUtils等工具做属性拷贝：适合DTO/VO转换，但注意BeanUtils是浅拷贝，嵌套对象会共享引用。

要我推荐的话，深拷贝用序列化，浅拷贝用BeanUtils或手动set。如果是性能敏感的高频操作，手写构造函数拷贝反而最可控。热搜里“java对象深度拷贝”大概率是项目中遇到了多层嵌套对象修改互相影响的问题，先想清楚拷贝边界比选工具更重要。

6.6 Java学习路线怎么安排最合理

每次看到热搜里“java学习路线”、“java自学路线图”，我就想起自己当初瞎折腾走了不少弯路。如果你是从零开始，比较好的顺序是：

• 第一个月：Java语法基础（数据类型、流程控制、数组、面向对象三大特性、异常、常用API），配合简单控制台项目。
• 第二个月：集合框架源码阅读（ArrayList/HashMap/LinkedList）、IO流、反射、注解。
• 第三个月：JVM内存模型与GC基础、并发编程（synchronized、volatile、ThreadLocal、线程池）。
• 第四个月：数据库（MySQL必学，重点是索引和事务）、JDBC、Maven、Git。
• 第五到六个月：Java Web（Servlet是过时了但过程值得过一遍）、Spring、Spring Boot、MyBatis。
• 第七到八个月：做一个完整的项目（比如权限管理系统、电商后台），把前端基础HTML/CSS/JS/Vue过一遍够用就行。
• 之后补Redis、消息队列、Linux、Docker。

这版路线偏保守但稳，核心思想是先广度后深度。基础阶段的每一天都在为后面的Spring源码打地基，尤其是反射和动态代理，不懂这两个看Spring AOP会非常痛苦。

7. 面试高频问题速查：拿得出手的答题框架

7.1 高频基础问题答题框架

有些基础问题翻来覆去地问，我整理一个答题顺序，按这个套路答不容易漏：

答题逻辑比背结论重要。面试官问HashMap，你要让他看到你是从“hash函数设计 -> 碰撞处理 -> 扩容 -> 并发问题”这个链路去理解的，而不是只记住“数组加链表”。

线程池这块也是基础中比较爱考的：ThreadPoolExecutor的核心参数是核心线程数、最大线程数、空闲存活时间、工作队列、线程工厂、拒绝策略。拒绝策略有AbortPolicy（默认，抛异常）、CallerRunsPolicy（调用者线程执行）、DiscardPolicy（直接丢弃）、DiscardOldestPolicy（丢弃最老任务）。实际配置CPU密集型和IO密集型不一样，IO密集型核心线程数一般设CPU核数两倍左右，具体要按压测结果来。

7.2 基础题里的换位思考

我在面试别人的时候，最怕听到的答案是“这个书上说就是这样”。比如问“为什么HashMap链表转红黑树的阈值是8”，如果对方只说“默认就是8”，那我基本判定他是背的。但如果说“理想状态下链表长度符合泊松分布，8是出现概率极低的临界值，而且红黑树节点占空间是链表节点两倍，转换要权衡空间和查询性能”，这就能看到思考深度。

同样的问题比如“为什么重写equals一定要重写hashCode”，如果只答“为了放进HashMap不出错”，太浅了。要补充：两个对象相等则hashCode必须相等，但hashCode相等的两个对象不一定相等；HashSet、HashMap等散列集合先比较hashCode定位桶，再比较equals确定是否同一个对象，如果不重写hashCode，就是Object默认的地址哈希，两个内容相同的对象会进不同桶，导致重复数据。

8. 实际项目里的Java基础应用片段

8.1 写API接口时的基础素养

热搜词里“java开发api接口以供外部调用”很对，Java写接口看起来简单，但基础不牢很容易翻车。几个基础层面的注意点：

• DTO返回统一封装结构，至少包含code、message、data三件套。
• 参数校验放Controller层做，用javax.validation注解体系，少写一堆if判断。
• 全局异常处理用@RestControllerAdvice，这样业务异常不会被用户直接看到堆栈。
• 接口日志要记得打，包括请求参数和响应结果，排查线上问题全靠它。

基础核心点在于：Java的异常体系、注解、泛型，在写接口时全部会被用到。比如统一返回结构通常要写一个泛型类Result<T>，如果泛型通配符不熟，这种类写起来会很别扭。

8.2 基础扎实的人在阅读源码时的优势

很多人问为什么Spring源码读不懂，答案通常是反射、泛型、设计模式基础不牢。Spring核心的BeanFactory在创建对象时就是通过反射调用构造器，依赖注入时通过反射解析字段上的@Autowired注解，代理对象通过动态代理生成，AOP通知链通过责任链模式组织和执行。

这些知识没有一个属于Spring本身，全是Java基础。所以我的建议一直是：如果源码看不下去，倒回去看Java基础，而不是硬啃框架。基础夹生的时候看Spring，每个类都认识，但组合起来的逻辑完全陌生；等你把反射和动态代理吃透了，再回头看Spring的getBean流程，会有那种“原来如此”的顿悟感。

9. 写在最后的两个建议

第一，基础复习不要只刷题，一定要带着“为什么”去复习。很多人在牛客、力扣上刷了大量选择题，知识点看着都眼熟，但面试让手写一个线程池配置或者讲讲ConcurrentHashMap的size怎么计算，立刻卡住。Java基础是一张知识网，背结论只能答对选择题，讲出推导过程才能应对追问。

第二，回顾知识的时候配合源码看，哪怕只看关键部分。ArrayList的扩容代码三五行就能看完，HashMap的put方法核心也不到五十行，看一遍源码比背十遍八股印象深得多。我自己的习惯是画一张“HashMap put流程”的脑图，把hash计算、碰撞、树化、扩容、fail-fast全部串起来，复习的时候扫一眼就能找回全部记忆。这个方法推荐给你。