三年Java开发面试经验：从基础到框架
“三年Java开发，面试了二十多家公司，最后发现考的根本不是框架用得多熟，而是你到底有没有理解底层。”——这是我从一个刚跳槽成功的前同事口中听到的原话。我深以为然。三年的经验，正处于一个尴尬的“进阶期”：你说自己是新人，公司觉得你该能独当一面；你说自己是资深，又离架构师差着好几年。面试官往往不会像应届生那样只问语法和CRUD，也不会像面高级工程师那样专攻系统设计。他们会在基础、框架、原理、场景、深度五个维度来回试探，试图判断你未来两年的成长潜力。
那么，究竟要怎样准备，才能在一场“三年经验”的Java面试中脱颖而出？我结合自己和身边朋友的真实经历，总结出下面这套从基础到框架的实战复盘。你不必死记硬背，但每一个加粗的观点，都可能成为你面试中让面试官“眼前一亮”的瞬间。
别再只会背“面向对象三大特征”
很多三年经验的候选人，开口就是“封装、继承、多态”，然后就开始背HashMap和ArrayList的区别。面试官听到这些，心里基本已经给你打了“平庸”的标签。三年经验最重要的标志，是你对Java类型系统的理解超越了语法层面。
比如，面试官问：“equals和hashCode为什么必须同时重写？”很多人能答出“为了HashMap的正常工作”，但不够。更深层的理解是：hashCode决定了对象在哈希表中的“桶”位置，而equals决定了桶内部的“精确匹配”。如果你只重写equals不重写hashCode，两个逻辑相等的对象会被放入不同桶，导致HashMap完全失效。更深入的问题是：“HashSet如何保证元素的唯一性？”本质还是依赖HashMap，而HashMap的put方法会先比较hashCode再比较equals。三年经验的面试者应该能脱口而出：如果两个对象的hashCode相等但equals不相等，会发生哈希冲突，形成链表或红黑树。
另一个高频坑：String、Integer、Long等包装类的缓存机制。面试官会问：“Integer a = 100; Integer b = 100; a == b 是true还是false？”很多人知道-128到127之间有缓存，所以是true。但三年经验的候选人应该能解释清楚IntegerCache的源码实现，并指出这依赖于JVM启动参数 -XX:AutoBoxCacheMax。更关键的是，如果你在项目中大量使用自动装箱和拆箱，面试官会追问并发场景下的线程安全问题——Integer本身不可变，但如果你用AtomicInteger会更好，因为CAS保证了原子性。
加粗核心：三年经验，你不仅要懂“是什么”，更要知道“为什么是这样设计”以及“在实际项目中踩过什么坑”。
JVM调优？别只会说“堆、栈、方法区”
面试官问JVM，大概率不是为了听你背《深入理解Java虚拟机》的目录。他们想听到的是你用过JVM监控工具解决过真实问题。比如：“线上CPU飙升100%，你怎么排查？”很多人的回答是“用top看进程，再用jstack看线程堆栈”。这个回答没错，但太通用。三年经验的面试者应该能说出具体的线程状态分析：如果大量线程处于RUNNABLE状态且堆栈指向一个同步方法，很可能是锁竞争激烈；如果大量线程处于BLOCKED状态，可能是死锁或长时间等待外部资源；如果线程处于WAITING状态，可能是线程池配置不当导致线程饥饿。
再比如：“你的应用频繁Full GC，怎么优化？”回答“增加堆内存”或“调大新生代”是常见的错误。真正的优化思路是先通过jstat查看GC统计，确认Full GC的原因：是元空间不足？是老年代无法容纳晋升对象？还是因为System.gc()被触发了？然后结合JVM参数和业务特点来调整。比如，一个短连接、高并发的服务，如果每次请求都创建大量临时对象，应该适当增大新生代，让这些对象在Minor GC阶段就回收掉，而不是晋升到老年代引发Full GC。
加粗：面试官真正想听的是你有过“用Arthas trace一个接口耗时”、或者“通过VisualVM分析堆转储发现内存泄漏”的经验。如果你能讲出一个具体的案例，比如“一个缓存服务因为没设置过期时间，导致Map对象无限增长，最终触发Full GC，我们用jmap dump分析后发现是ConcurrentHashMap全被某个业务key占满”，这比任何理论都加分。
并发编程：不要停留在synchronized和volatile
三年经验的Java开发者，面试中的并发编程题往往决定了你是“中级”还是“高级”的分水岭。面试官会直接问：“synchronized和Lock有什么区别？”你需要从锁的获取释放、可中断性、公平性、绑定多个条件、性能等维度对比。但仅仅对比还不够，三年经验的候选人应该能讲出synchronized在JDK 1.6之后的优化：偏向锁、轻量级锁、锁消除、锁粗化。比如，你能否解释为什么在无竞争下使用synchronized性能比Lock还好？因为JVM会偏向第一个获得锁的线程，通过CAS在对象头Mark Word中记录线程ID，避免系统调用。
另一个必问的题目：“ThreadLocal的内存泄漏问题怎么避免？”很多人知道在使用完后用remove()清除。但更深入的理解是：ThreadLocalMap的key是弱引用，value是强引用，所以当ThreadLocal被GC后，key变成null，但value仍然存在，导致内存泄漏。解决思路除了手动remove，还可以使用InheritableThreadLocal或TransmittableThreadLocal处理跨线程传递。三年经验的工程师应该能给出在你项目中的实际使用场景，比如在Spring事务管理中用ThreadLocal存储数据库连接，或者在拦截器中存放用户上下文。
加粗：并发最难的不是API，而是对“可见性、有序性、原子性”的直觉。面试官可能会让你写一个“三个线程交替打印数字”的题目，这不仅是考察你会用Lock/Condition，更是考察你是否理解线程通信的底层机制。如果你能自然地说出“用volatile修饰一个共享变量，配合CAS自旋也可以实现，但CPU忙等待会浪费资源”，面试官会认为你真正理解了无锁编程的优缺点。
Spring框架：源码级理解是门槛
三年经验，面试官默认你天天用Spring Boot，但他们会问：“Spring IoC容器启动流程是怎样的？”很多人会答：“读取配置文件，创建Bean，注入依赖。”这太笼统。你需要像讲故事一样说出关键步骤：先调用refresh()方法，里面包含prepareRefresh（设置容器状态）、obtainFreshBeanFactory（加载BeanDefinition）、invokeBeanFactoryPostProcessors（处理BeanFactoryPostProcessor）、registerBeanPostProcessors（注册BeanPostProcessor）、finishBeanFactoryInitialization（实例化所有非懒加载单例Bean）等十几步。面试官可能打断你，问你“BeanPostProcessor和BeanFactoryPostProcessor有什么区别？”——前者在Bean实例化前后修改Bean属性，后者在Bean定义加载后修改BeanDefinition元数据。
另一个高频题：“Spring AOP的底层原理是什么？JDK动态代理和CGLIB有什么区别？”三年经验的候选人必须能回答：JDK动态代理要求目标类实现接口，通过反射生成代理对象；CGLIB通过字节码增强生成目标类的子类，因此无法代理final方法。而且，Spring Boot默认使用CGLIB，因为无需接口。但如果你在面试中说“CGLIB比JDK动态代理快”，面试官可能会反问：“为什么Spring还保留了JDK动态代理？”因为JDK动态代理基于原生反射，在早期JDK版本中比CGLIB慢，但JDK 8之后性能大幅提升，而且CGLIB需要依赖ASM字节码库。更聪明的回答是：实际业务中性能差异可以忽略，选型更多取决于目标类是否编写了接口。
加粗：如果你还能说出Spring事务的传播行为在底层是如何通过AOP和ThreadLocal实现的，并且指出“同一个类内部方法调用会导致事务失效”的经典坑，面试官基本就会给你高分了。因为这个问题考察了对代理机制和@Transactional注解生效条件的理解。
MyBatis & 数据库：别只写CRUD
三年经验，面试官默认你会写SQL，但他们会问：“MyBatis的#{}和${}有什么区别？”基础回答是：#{}预编译防SQL注入，${}直接拼接字符串。三年经验的进阶回答是：在实际项目中，如果需要在ORDER BY或表名处动态拼接，必须用${}，此时需要手动过滤危险字符。同时，你应该了解MyBatis的缓存机制：一级缓存默认开启（SqlSession级别），二级缓存需要配置（namespace级别），它们底层依赖HashMap或ConcurrentHashMap。面试官可能会追问：“一级缓存什么时候会失效？”——执行commit、close、update操作都会清空缓存。
数据库面试则更趋向于索引、锁、优化。比如：“给你一个慢查询，explain结果中type是ALL，你怎么优化？”三年经验的人应该能一步步分析：先看是否有合适的索引，再看查询条件是否导致索引失效（比如对索引列使用了函数或隐式类型转换），然后考虑是否可以使用覆盖索引，最后可能考虑分库分表或读写分离。加粗：面试官特别喜欢问“你遇到过的线上数据库死锁案例”。如果你能讲出一个实际案例，比如“订单表和库存表更新顺序不一致导致死锁，最后通过统一加锁顺序解决”，这远比背死锁条件有价值。
分布式与微服务：不要只会说“Ribbon负载均衡”
很多三年经验的面试者一提到微服务就开始背八股文：Eureka、Feign、Gateway、Sentinel…但面试官会问：“你公司为什么选择这个注册中心？Eureka和Nacos有什么区别？”你需要说出Eureka遵循AP（可用性和分区容错性），而Nacos支持AP和CP切换，适合不同业务场景。并且，如果你们的服务规模不大（几十个实例），Eureka的自我保护模式会导致服务列表长时间不更新，这时候使用Consul或Kubernetes Service可能更好。
另一个常见问题：“RPC调用超时和重试你怎么设计？”三年经验的候选人应该能说出基于Spring Cloud的Ribbon超时配置（ConnectTimeout和ReadTimeout的区别），以及如何通过Hystrix或Sentinel做熔断降级。但更深入的思考是：重试是否幂等？如果下游接口是插入操作，重试会导致重复数据，必须配合全局唯一ID去重。面试官还会追问“如果服务A调用B，B调用C，C调用D，一条链路超长怎么优化？”——这涉及了分布式追踪、异步化、数据异构等思路。
加粗：三年经验，面试官最怕你只会“调API”，而没有参与过“服务拆分、数据库分库分表、分布式事务”的实践。如果你能讲一个具体的分布式事务案例（比如TCC、Saga模式，或者基于本地消息表+MQ最终一致性），那就是很大的加分项。
系统设计：从“会做”到“会设计”
三年经验的面试，最后一轮往往是个简单的系统设计题，比如“设计一个短链接系统”或“设计一个秒杀系统”。不要觉得这是架构师才该会的东西，面试官就是想看看你有没有面向对象设计+场景分析的全局思维。比如设计短链接生成：你需要考虑发号器算法（Snowflake？数据库自增ID？），映射存储（Redis + MySQL的关系），以及过期策略。三年经验的工程师应该能说出“用预发号ID段+本地缓存”来提升并发能力，而不是傻傻每次都查数据库。
再比如秒杀系统：你会被问到“怎么防止超卖？”——大多数人回答“用乐观锁”。但面试官会继续问：“乐观锁在极高并发下会导致大量失败，怎么优化？”你需要提出“库存扣减放在Redis中，通过Lua脚本保证原子性”，或者“把库存分段分片，减少锁冲突”。这些方案不仅体现了你对中间件的理解，还体现了你在高并发场景下的实战推理能力。
加粗：最重要的不是给出标准答案，而是展示出你“从0到1构建合理架构”的思考过程——包括数据量预估、网络延迟考量、容灾降级等。
写在最后：三年经验不是终点，而是新起点
当你走完上面这套从基础到框架的面试复盘，你会发现：三年经验最核心的价值，不是你会背多少面试题，而是你能够把学到的东西和实际项目结合起来，说出为什么这么选，踩过什么坑，最终怎么解决。面试官要的从来不是一个“答案机器”，而是一个有工程师思维、能独立思考、愿意深挖原理的潜在骨干。扎实的基础会让你走得更远，而框架之外的广度会让你遇到瓶颈时知道从哪里找突破口。最后送你一句话：面试不是要证明你什么都会，而是要让面试官觉得——“这个人在团队里，我会放心把复杂问题交给他。”