Java Bug 避坑指南：小白与架构师的深夜 Debug 实录
夜深了，办公室的灯光下，刚入职的 Java 开发小白正抓耳挠腮地对着屏幕上的红字报错叹气。旁边的资深架构师大牛端着咖啡走了过来，看到小白的窘境，笑着拉了把椅子坐下。
“怎么了，又被 Bug 拦住去路了？”大牛问道。
小白仿佛看到了救星：“大牛哥，这些报错简直是我的噩梦，不仅有基础的，还有框架和中间件的，我感觉我的头发都要掉光了。”
大牛喝了一口咖啡，淡定地说：“别慌，Bug 是程序员进阶的垫脚石。来，我们分几个回合，把你遇到的问题一个个解决掉。”
第一回合：Java 核心与集合框架的“坑”
小白：“大牛哥，我先问两个基础的。第一个，我明明只是想在遍历List的时候把符合条件的元素删掉，结果报了个java.util.ConcurrentModificationException，这是为什么啊？”
大牛：“这是新手最容易犯的错。你肯定是用foreach循环或者普通的for循环直接调用list.remove()了吧？在 Java 中，增强for循环底层是用迭代器（Iterator）实现的。当你直接用集合的方法删除元素时，集合的结构修改计数器（modCount）变了，但迭代器不知道，这就导致了并发修改异常。解决方案：
- 推荐：使用 Java 8 的
removeIf方法，一行代码搞定：list.removeIf(e -> e.getId() == 1);。 - 传统：显式调用
Iterator，使用iterator.remove()方法来安全删除。”
小白：“原来如此！还有一个，我定义了一个Integer类型的变量接收数据库查出来的年龄，结果报了NullPointerException。通过 Debug 我发现数据库里那个字段是空的，可我用的是对象类型啊？”
大牛：“这涉及到了自动拆箱。如果你的代码里有类似int age = user.getAge()的操作，虽然 User 对象里的age是Integer（可以是 null），但当你把它赋值给基本数据类型int时，JVM 会自动尝试拆箱调用intValue()。如果对象是 null，这一步就会空指针。解决方案：
- 始终做好判空检查。
- 接收变量也使用包装类
Integer而不是int。 - 使用
Optional类来优雅地处理可能为空的值。”
第二回合：Spring 全家桶与 MyBatis 的“雷”
小白：“基础的懂了，现在是框架问题。我启动 Spring Boot 项目时，控制台狂刷BeanCurrentlyInCreationException，说是什么 Circular reference，这是啥？”
大牛：“这是循环依赖。简单说就是 A Service 注入了 B Service，B Service 又注入了 A Service。Spring 容器在创建 Bean 时不知道该先创建谁了。虽然 Spring 默认的三级缓存能解决大部分 Setter 注入的循环依赖，但如果是构造器注入或者涉及异步代理，就会报错。解决方案：
- 临时方案：在其中一个注入字段上加
@Lazy注解，让它延迟加载。 - 根本方案：重构代码。通常循环依赖意味着代码结构设计不合理，建议抽取出第三个 Service 或者使用设计模式（如观察者模式）来解耦。”
小白：“受教了！还有个 MyBatis 的问题特别玄学，报org.apache.ibatis.binding.BindingException: Invalid bound statement (not found)。我检查了 Mapper 接口和 XML 文件，名字都对得上啊！”
大牛：“这个报错能排进 MyBatis 问题榜单前三。它意味着接口找到了，但对应的 SQL 没找到。解决方案：依次检查这三点：
- 命名空间：XML 中的
namespace必须全路径匹配 Mapper 接口。 - 方法名：接口方法名和 XML 中的
id是否完全一致（注意空格）。 - 资源编译（最常见）：如果你的 XML 放在
src/main/java目录下，Maven 默认是不会把 XML 编译到target目录的。你需要在pom.xml的<build>标签下配置<resources>，把src/main/java目录下的.xml文件包含进去。”
小白：“还有一个！我在一个方法上加了@Transactional，结果里面抛异常了，数据库居然没回滚！”
大牛：“你是不是在方法内部自己用try-catch把异常给吃掉了？”小白：“对啊，我想记录一下日志……”大牛：“这就是原因。Spring 的事务切面默认只捕获未被处理的RuntimeException。你把异常捕获了，AOP 认为业务执行成功，自然就提交事务了。解决方案：
- 在
catch块中手动抛出异常：throw new RuntimeException(e);。 - 或者在
catch块中手动设置回滚：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();。”
第三回合：中间件与分布式的“坑”
小白：“大牛哥，最后问问中间件的。我用 Redis 缓存对象，结果取出来的时候报java.lang.ClassCastException，但我明明存进去的就是那个类啊？”
大牛：“这通常是序列化的问题。如果你用的是默认的JdkSerializationRedisSerializer，它对类路径和版本很敏感。或者你用了 JSON 序列化，但在反序列化时，Redis 里的 JSON 结构和你的 Java 实体类字段对应不上（比如你改了类名或包名）。解决方案：
- 推荐使用
GenericJackson2JsonRedisSerializer，并配置好 ObjectMapper。 - 确保写入和读取使用相同的序列化策略。
- 如果是版本升级导致的字段变更，要在实体类上做好
@JsonIgnoreProperties(ignoreUnknown = true)容错处理。”
小白：“最后一个问题，RabbitMQ 消息丢了！我明明发送成功了，但消费者重启后，之前的消息就不见了。”
大牛：“这涉及消息持久化。RabbitMQ 默认把消息存在内存里，重启当然就没了。要保证不丢消息，必须做全套持久化。解决方案：
- Exchange 持久化：声明交换机时
durable设为true。 - Queue 持久化：声明队列时
durable设为true。 - Message 持久化：发送消息时设置
deliveryMode为 2。 只有这三者同时满足，消息才会落盘保存。”
大牛的总结：
大牛拍了拍小白的肩膀，语重心长地说：“小白，报错不可怕，报错其实是程序在告诉你它哪里‘不舒服’。从 Java 集合的底层原理，到 Spring 的 Bean 生命周期，再到中间件的持久化机制，每一个 Bug 背后都是一个知识点。遇到报错，先看堆栈信息，再分析源码原理，最后才是搜索解决方案。保持这种好奇心和钻研劲儿，你很快就能成为独当一面的资深开发了。继续加油吧！”
小白看着屏幕，眼里的迷茫散去，重新燃起了斗志：“谢谢大牛哥，我这就去修 Bug！”