Java程序调试：抽丝剥茧，锁定意外的delete操作
在Java应用开发中，排查代码错误是家常便饭。本文以一个用户状态更新后数据丢失的案例为例，演示如何利用异常信息精准定位问题根源。
问题描述： 用户注册并完成邮箱验证后，程序应执行update操作更新用户状态。然而，用户信息却意外丢失。开发者怀疑问题出在user.xml文件中定义的delete语句（如下），并已将其删除，但控制台依旧报错：
<delete id="delete">
delete from user where email=#{email}
</delete>
控制台异常信息如下：
立即学习“Java免费学习笔记（深入）”；
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
<code>org.apache.ibatis.binding.BindingException: Invalid bound statement (not found): com.mooc.house.biz.mapper.UserMapper.delete
at org.apache.ibatis.binding.MapperMethod$SqlCommand.<init>(MapperMethod.java:230) ~[mybatis-3.4.2.jar:3.4.2]
at org.apache.ibatis.binding.MapperMethod.<init>(MapperMethod.java:48) ~[mybatis-3.4.2.jar:3.4.2]
... ... (省略部分堆栈信息) ... ...
at com.mooc.house.web.controller.UserController.verify(UserController.java:47) [classes/:?]
... ... (省略部分堆栈信息) ... ...</code>
即使删除了user.xml中的delete语句，异常信息仍然提示Invalid bound statement (not found)，说明代码中仍有地方尝试调用这个已不存在的语句。关键在于分析堆栈信息，找到这个调用点。
堆栈信息分析： 仔细观察堆栈信息，我们可以看到关键线索：com.mooc.house.biz.service.MailService$1.onRemoval(MailService.java:34)。这行信息指出异常发生在MailService.java文件的第34行，onRemoval方法内。结合代码片段，我们发现MailService类使用了Guava缓存，并在缓存移除监听器RemovalListener的onRemoval方法中调用了userMapper.delete：
private final Cache<String, String> registerCache = CacheBuilder.newBuilder().maximumSize(100)
.expireAfterAccess(15, TimeUnit.MINUTES)
.removalListener(new RemovalListener<String, String>() {
@Override
public void onRemoval(RemovalNotification<String, String> notification) {
userMapper.delete(notification.getValue());
}
}).build();
enable方法调用registerCache.invalidate(key)会触发缓存移除，进而调用onRemoval方法，最终执行userMapper.delete。因此，问题根源在于MailService的缓存移除监听器中不恰当的delete操作。堆栈信息中的其他部分，例如UserService.enable和UserController.verify，展示了完整的调用链，说明enable方法最终由UserController.verify方法调用。
通过分析堆栈信息，我们成功追踪到调用delete操作的代码位置，从而解决了数据丢失的问题。
