社区问答区里泡久了你会发现 Java 板块的提问翻来覆去就那么几类一段代码跑出来的结果和预期不一样、线上偶发一个说不清的异常、某个注解加了却像没加。标题起得五花八门点进去看根子大多落在几个老地方——对象语义没吃透、共享可变状态没管住、容器和框架的默认行为没搞清楚。这些问题单看都很碎但它们背后的认知缺口高度重合所以我一直想找个机会把它们按层拆一遍。这篇东西不是面试题合集也不是 API 手册。它解决的是“看到一段有问题的 Java 代码我该从哪一层开始怀疑”这个问题。适合工作一到三年的开发也适合带新人的同学拿去当排查思路的参照。读完之后你至少能做到两件事别人贴一段代码问为什么不对你能在三分钟内判断问题出在语义层、并发层还是框架层自己写代码时能提前避开那批最容易踩的坑。1. 这些问题为什么值得单独拎出来讲1.1 一个提问背后往往藏着三层认知缺口我观察过大量提问帖发现一个规律提问者描述的“现象”和他真正的“问题”经常不是一回事。有人问“为什么我的 HashSet 里出现了两个一模一样的对象”现象是集合行为异常真正的问题是equals和hashCode只重写了一半。有人问“为什么加了锁还是超卖”现象是并发不安全真正的问题是他锁的对象每次都在变。再往下挖还有一层他根本不知道自己不知道什么。比如很多人从没意识到 Java 的整数装箱是有缓存的比较两个Integer有时候是 true 有时候是 false于是他把这当成“玄学”绕着走而不是去搞明白规则。这三层缺口对应的解决方式完全不同。现象层只需要改代码语义层需要补概念认知层需要重建判断习惯。如果只按现象给答案提问的人下个月还会拿一个变形的问题回来问。1.2 这类内容真正的价值在“判断顺序”而不是“标准答案”我不太喜欢直接给答案。Java 的很多问题有多个“正确”答案取决于版本、取决于使用场景、取决于你到底想要什么语义。比如问“字符串拼接用还是StringBuilder”答案是“看你在哪拼”。单条表达式里编译器自己就优化了循环里手写就是自找麻烦。真正有价值的是判断顺序先确认事实再定位层次最后才谈方案。这个顺序错了后面全是白费功夫。我见过太多人一上来就怀疑框架有 bug查了三个小时最后发现是自己类没被 Spring 管理。所以下面我按“语义、并发、集合性能、框架、排查”这五层来组织每层挑几个被问得最多的问题把现象、根因、验证方法、修正方案都摆出来。你可以把它当成一份排查地图遇到新问题的时候先定位它在哪一层再往下查。2. 先给问题分个层把“报错”翻译成“知识点”2.1 四类高频问题的共同特征我把社区里反复出现的 Java 问题归成四类每类的特征很鲜明。语义类问题的特征是“结果确定但不符合直觉”。同样的代码跑一百次都是一样的错误结果这恰恰说明它不是偶发 bug而是你对语言规则的理解有偏差。典型代表是与equals的区别、基本类型与包装类型的转换、重载方法的解析顺序。并发类问题的特征是“偶发、难复现、加日志就消失”。这类问题最耗时间因为你在本机跑一万次都正常上线之后一天出一次。典型代表是共享SimpleDateFormat、非原子自增、可见性问题。集合与性能类问题的特征是“功能对但慢或者内存涨”。这类问题不会立刻暴露往往在数据量上去之后才显现。典型代表是循环里拼字符串、集合没预设容量、无界队列堆积。框架类问题的特征是“配置看起来没问题但就是不生效”。这类问题最容易被误判为框架 bug。典型代表是事务注解失效、异步注解失效、循环依赖启动报错。分清这四类你就知道该往哪个方向找证据。语义类去看代码本身并发类去看共享状态性能类去看数据量和调用频次框架类去看代理和容器管理。2.2 我常用的分类框架与判断顺序具体怎么判断我做了一张对照表遇到问题时按“现象关键词”先去匹配能省掉大量试错时间。现象关键词大概率所属层第一件该确认的事常用验证手段结果稳定复现、逻辑看着没问题语义层涉及的类型是基本类型还是包装类型打印getClass()和实际值偶发、并发量上来才出现并发层有没有共享的可变对象压测复现、加线程数单次正常、批量处理变慢性能层循环内有没有重复创建大对象打时间戳分段计时注解加了但行为没变框架层当前调用是否经过代理打印this.getClass()看是否被代理判断顺序上我的习惯是“先排除简单解释”。如果一个问题是稳定复现的那它百分之百是代码逻辑或语言规则问题跟并发、跟框架都没关系别浪费时间去看源码。反过来如果一个问题只在压力下出现先别急着改逻辑先确认是不是共享状态。这里有个很多人会忽略的细节代理对象的类名和原始类名不一样。你在被 Spring 管理的 bean 里打印this.getClass().getName()如果看到类似XxxService$$EnhancerBySpringCGLIB$$...这样的名字说明它被代理了如果是干净的类名说明某些代理机制没生效事务、异步这些依赖代理的功能自然也失效了。这一招在排查注解失效时特别好使。提示判断代理是否生效比翻文档快十倍。打印一次类名胜过查半小时配置。3. 语义层那些“看起来对、跑起来错”的坑3.1 equals 与 hashCode 的契约破坏一半会怎样这是社区里被问得最多的问题没有之一。提问形式通常是“我往HashSet里加了两个内容一样的对象为什么 size 是 2”根本原因是 Java 对equals和hashCode有一条明确契约如果两个对象equals返回 true它们的hashCode必须相等。如果你只重写了equals两个内容相同的对象会有不同的哈希值落到哈希表的不同桶里压根不会触发equals比较于是“重复”就被放进去了。public class User { private String name; private int age; public User(String name, int age) { this.name name; this.age age; } Override public boolean equals(Object o) { if (this o) return true; if (!(o instanceof User)) return false; User user (User) o; return age user.age Objects.equals(name, user.name); } // 故意不重写 hashCode public static void main(String[] args) { SetUser set new HashSet(); set.add(new User(A, 20)); set.add(new User(A, 20)); System.out.println(set.size()); // 输出 2不是 1 } }哈希表的查找逻辑是两步先用hashCode定位桶再在桶里用equals逐个比较。第一步定位错了后面的比较根本不会发生。所以正确的做法是两个一起重写且参与计算的字段要一致——equals里用了name和agehashCode里也得用这两个。还有一个更隐蔽的坑对象作为 key 之后修改了参与哈希计算的字段。比如你把User放进HashMap之后改了name这个 key 的哈希值变了再用它去get就找不到了。这不是HashMap的 bug是你违反了自己声明的契约。我在实际项目里碰到过一次排查了整整一个下午最后发现是缓存层复用了同一个可变对象当 key。提示凡是进集合当 key、或者进Set去重的对象尽量设计成不可变对象。改不了就不会有哈希漂移。3.2 Integer 缓存与 的关系第二个高频问题“为什么Integer a 127; Integer b 127;打印 true换成 128 就变成 false 了”这属于典型的语义层认知缺口很多人把它当成编译器抽风。实际规则很清晰Integer的自动装箱走的是Integer.valueOf(int)这个方法内部维护了一个缓存数组默认范围是 -128 到 127。落在这个范围内的整数直接返回缓存对象所以两次装箱拿到的是同一个引用比较自然为 true。Integer a 127; Integer b 127; System.out.println(a b); // true命中缓存 Integer c 128; Integer d 128; System.out.println(c d); // false超出缓存各自 new Integer e new Integer(127); System.out.println(a e); // falsenew 一定创建新对象 System.out.println(a.equals(e)); // trueequals 比的是值缓存上限默认是 127可以通过启动参数-XX:AutoBoxCacheMax1000调整但它调的是上限下限 -128 是写死的。这个问题在业务代码里的实际危害比你想象的大。我见过有人用比较订单金额的Integer字段测试环境金额小全部命中缓存跑得飞快生产环境订单一过千判断集体失效变成了“金额不同的两笔订单被判为相等”。这种 bug 不报错、不抛异常只是默默算错。结论很干脆包装类型的值比较一律用equals或者先转成基本类型再比。别依赖缓存范围那是实现细节不是语义保证。3.3 i 的原子性错觉与 volatile 的边界“我加了 volatile为什么自增还是会少”这个问题的提问频率仅次于前面那个。先看代码public class Counter { private volatile int count 0; public void increment() { count; // 这不是一个原子操作 } }count在字节码层面是四步读取字段值、压入常量 1、执行加法、写回字段。volatile保证的是可见性和禁止重排序不保证这四步作为整体不被打断。线程 A 读到 5还没写回线程 B 也读到 5两个线程各自加一写回最终结果是 6 而不是 7。解决办法有三个层次的取舍。最低成本是加锁synchronized或者ReentrantLock正确但吞吐差。第二种是用AtomicInteger的incrementAndGet()基于 CAS 循环无锁且正确适合竞争不激烈的场景。第三种是高竞争场景用LongAdder把热点分散到多个单元格上最后求和吞吐更高但只能拿到最终结果中途读取的值不精确。private final AtomicInteger counter new AtomicInteger(0); public void increment() { counter.incrementAndGet(); }注意volatile的正确用途是“一个线程写、多个线程读”的状态标记比如volatile boolean running。凡是涉及“读—改—写”复合操作的它都顶不住。这里还牵出一个常被忽略的点volatile的可见性保证是有前提的它保证的是对这个变量的读写不会被缓存到线程本地但不保证复合操作的原子性。这两个概念经常被混为一谈导致有人觉得“加了 volatile 就线程安全了”。真要建立正确认知得把 Java 内存模型里“原子性、可见性、有序性”这三件事分开理解缺一不可。4. 并发层共享可变状态是万恶之源4.1 SimpleDateFormat 出错的真实原因这个坑几乎每个团队都踩过。现象是日期格式化偶尔出现乱码、年份变成奇怪的数字或者直接抛NumberFormatException。而且诡异的是本地单线程测试永远正常。根因在于SimpleDateFormat内部持有一个Calendar对象作为可变状态format和parse方法都会先 clear 再 set 这个 Calendar。多个线程共用一个实例时A 线程刚 set 完年份B 线程把整个 Calendar 清了A 再去读就拿到了脏数据。解决办法按推荐程度排序。第一选择是换成DateTimeFormatter它是不可变且线程安全的配合LocalDateTime、LocalDate使用API 也更清晰private static final DateTimeFormatter FORMATTER DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); public String format(LocalDateTime time) { return FORMATTER.format(time); } public LocalDateTime parse(String text) { return LocalDateTime.parse(text, FORMATTER); }如果因为历史原因必须用SimpleDateFormat那就用ThreadLocal每个线程一份或者每次方法内 new 一个——后者在小流量下完全没问题别为了省一个对象搞出并发 bug。至于synchronized包一层正确但会把这行代码变成串行点高频调用下得不偿失。我在实际项目里做过一次统计一个中等流量的接口每次请求 new 一个DateTimeFormatter是完全可接受的因为它本身就是不可变对象构造开销很小。真正贵的是SimpleDateFormat那种带内部状态的类。所以选型的时候优先看“是否可变”而不是“是否 new”。4.2 线程池参数该怎么算队列怎么选线程池的问题在社区里分两派一派问参数怎么配一派问为什么不生效。先解决配参数。参数计算有个常用的经验公式。设 CPU 核数为 NCPU 密集型任务大量计算、少量等待核心线程数设为 N 1。多出来的一个用于在某个线程偶发缺页或短暂阻塞时顶上。IO 密集型任务大量数据库查询、远程调用核心线程数设为 N × (1 平均等待时间 / 平均计算时间)。这个公式的本质是让 CPU 在等待期间有活可干。举个例子8 核机器任务平均计算 10 毫秒、等待 90 毫秒那么理想线程数是 8 × (1 9) 80。当然这是理论上限实际还要考虑下游数据库能扛多少并发别把压力全推给数据库。比参数更容易出错的是队列的选择。很多人用默认的Executors.newFixedThreadPool它内部是无界队列任务堆积起来永远不会触发拒绝策略内存一路涨到 OOM。正确的做法是显式指定有界队列比如new ArrayBlockingQueue(200)队列满了触发拒绝策略。拒绝策略我优先选CallerRunsPolicy它让提交任务的线程自己执行形成天然的背压——线程池忙不过来时上游会被拖慢而不是把任务丢掉或者抛异常。这在 web 场景下比AbortPolicy温和得多。还有一个执行顺序的细节很多人搞反了线程池接到任务后先看核心线程数满没满没满就新建线程满了就进队列队列满了才把线程数扩到最大最大也满了才走拒绝策略。也就是说队列容量设得太大最大线程数永远用不上。这个顺序搞明白配参数的时候就不会盲目调大队列。4.3 双重检查锁为什么少不得 volatile单例模式的双重检查写法是并发层里被讨论最多的一段代码public class Singleton { private static volatile Singleton instance; public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }为什么必须加volatile因为instance new Singleton()在字节码层面分三步分配内存、初始化对象、把引用赋给变量。步骤二和步骤三在某些处理器上可能重排序。如果发生重排另一个线程在第一次判空时可能看到一个非 null 但还没初始化完成的对象然后拿着它去用拿到的字段全是默认值。volatile在这里的作用是禁止这个重排序保证“初始化完成”一定发生在“引用可见”之前。少了这个关键字代码在单线程下永远正确在多线程下概率性出错——最难查的那一类。顺带说一句实际项目里我更推荐静态内部类写法靠类加载机制保证线程安全代码还更短public class Singleton { private Singleton() {} private static class Holder { private static final Singleton INSTANCE new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }类加载是线程安全的INSTANCE在类初始化时创建天然延迟加载。除非你需要传参构造否则没理由手写双重检查。5. 集合与性能别让容器替你的疏忽买单5.1 ArrayList 扩容的代价与预设容量ArrayList的默认初始容量是 10但这个数组是在第一次add时才分配的构造时只是给了一个共享的空数组。之后每次容量不够按oldCapacity (oldCapacity 1)扩容也就是 1.5 倍然后调用Arrays.copyOf把老数据整体复制过去。单次扩容不贵但累积起来很可观。假设你要装 100 万个元素从 10 开始一路 1.5 倍扩上去中间会经历二十多次扩容累计复制的元素数量大约是最终规模的两倍多。如果预先知道规模直接new ArrayList(1000000)一次分配到位省掉所有复制。// 不推荐默认容量反复扩容 ListOrder list new ArrayList(); for (Order o : orders) { list.add(o); } // 推荐已知规模直接指定 ListOrder list new ArrayList(orders.size());还有一个反直觉的点ArrayList删除元素比添加贵得多。remove(i)之后要把后面所有元素往前挪一位是 O(n) 操作。如果在循环里做删除用迭代器的remove或者干脆倒序遍历避免索引错位。这个坑我在写批量处理逻辑时踩过删除条件命中率高的时候性能直接从秒级掉到分钟级。5.2 HashMap 的 8 和 64 到底在防什么面试常问“HashMap的树化阈值为什么是 8”很多人背了答案但没理解。这里说清楚。HashMap在链表长度达到 8 且数组容量至少 64 时会把链表转成红黑树。选 8 这个数不是拍脑袋是基于泊松分布的统计结果在哈希函数分布均匀的理想情况下一个桶里链表长度达到 8 的概率大约是千万分之六。也就是说正常情况下你几乎遇不到树化一旦遇到说明哈希分布出了问题比如大量 key 的hashCode冲突这时候需要红黑树把查询从 O(n) 拉回 O(log n)。MIN_TREEIFY_CAPACITY 64这个条件更值得注意。当数组容量还小的时候即使链表长了也优先扩容而不是树化——扩容会把元素重新打散到更多桶里可能冲突就自然消失了。扩容比维护红黑树便宜。所以真实的判断顺序是链表长度到 8先看数组容量够不够 64不够就扩容够了才树化。退化阈值是 6不是 8中间留了一个缓冲防止在 7、8 之间反复横跳来回转换结构。实际使用上的建议只有一条能预估规模就指定初始容量。比如确定要放 1000 个元素按负载因子 0.75 反推初始容量设 1024 就够能避免多次扩容。但别设得过于精确扩容的触发条件是size capacity * 0.75卡在边界上很容易多扩一次。5.3 循环里拼字符串为什么慢得离谱这个问题在社区里出现频率极高代码通常长这样String result ; for (int i 0; i 10000; i) { result i; }看起来没什么实际复杂度是 O(n²)。因为String是不可变的每次都会创建一个新的StringBuilder、append 进去、再toString()生成新字符串上一轮的字符串变成垃圾。一万次循环意味着创建一万个StringBuilder和一万个中间字符串GC 压力巨大。StringBuilder sb new StringBuilder(10000 * 5); for (int i 0; i 10000; i) { sb.append(i); } String result sb.toString();这里我还想补一个容易被忽略的细节编译器确实会优化字符串拼接但只在单条表达式内。像a b c这样的单句编译器会合成一次StringBuilder操作。但循环里的涉及跨迭代的状态编译器不会帮你提到循环外面只能老老实实每次都 new。StringBuilder和StringBuffer的选择也很简单单线程用前者需要线程安全用后者。但说实话我极少见到真正需要StringBuffer的场景因为字符串拼接几乎总在方法内部的局部变量上进行天然线程隔离。把共享的StringBuilder当成员变量用才是真正该警惕的写法。6. 框架层注解不生效的几种典型姿势6.1 事务失效的六种场景与自检清单“我加了Transactional为什么还是脏数据”这个问题在问答区几乎每周都有人问。事务失效的原因很集中我列成清单遇到问题逐条排查就行。场景失效原因修正方式同类内部方法直接调用走的是this不经过代理拆到另一个 bean或注入自身代理方法不是 public早期版本代理无法拦截非 public 方法改成 public异常被自己 catch 了容器感知不到异常不会回滚别吞异常或手动setRollbackOnly抛的是受检异常默认只对RuntimeException和Error回滚加rollbackFor Exception.class在新线程里调用事务绑定在线程上下文上跨线程丢失别在异步线程里指望外层事务类没被容器管理自己new出来的对象没有代理交给容器管理第一条是最容易中招的。this.saveOrder()这种调用看起来是“调了自己的方法”实际上绕过了代理对象事务拦截器根本没机会介入。解决办法要么把方法挪到另一个 bean 里要么注入自己的代理引用注意可能有循环依赖问题需要配Lazy。第四条也很典型。很多团队封装了统一的业务异常继承自Exception抛出去之后事务不回滚数据已经写了一半。这类问题在测试环境很难发现因为测试用例通常不校验数据一致性。提示排查事务问题第一步永远是确认当前对象是不是代理对象。打印类名一秒见分晓。6.2 循环依赖为什么能解决又为什么有时解决不了Spring 用三级缓存解决单例 bean 的循环依赖一级缓存放完整对象二级缓存放早期暴露的对象三级缓存放对象工厂。A 依赖 B、B 依赖 A 时A 实例化后先把工厂放进三级缓存去填充 B 的属性B 需要 A 时从三级缓存拿到早期引用B 完成初始化A 再完成初始化。但有两种情况它解决不了。第一种是构造器注入的循环依赖因为对象还没实例化完压根没有引用可以提前暴露。第二种是原型作用域的循环依赖容器不缓存原型 bean。实际项目里循环依赖能解决不代表应该存在。我见过一个 service 里注入了七八个其他 service互相之间还打转最后靠三级缓存勉强启动。这种设计一旦有改动就容易炸。合理的做法是把公共逻辑下沉到更细的组件或者用事件机制解耦。真遇到启动报错第一反应应该是“我的依赖关系画错了吗”而不是“怎么把这个错绕过去”。6.3 Async 静默失败的排查路径Async的问题特点是不报错、不生效、毫无提示。方法照常返回只是变成同步执行了。排查路径我固定成三步。第一看注解所在的方法是不是被同类内部调用如果是跟事务失效是同一个原因没走代理。第二看启动类或配置类上有没有开EnableAsync这个漏了的情况非常多因为编译期不报错。第三看有没有自定义线程池不配的话默认用SimpleAsyncTaskExecutor每次调用新建线程且不复用在高并发下会直接把线程数打爆。Configuration EnableAsync public class AsyncConfig { Bean(bizExecutor) public Executor bizExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(200); executor.setThreadNamePrefix(biz-async-); executor.setRejectedExecutionHandler( new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }另外注意返回值。异步方法返回void时异常会被吞掉你连出错都不知道返回Future或CompletableFuture才能拿到异常。生产环境我建议一律返回CompletableFuture至少留个可以捕获异常的口子。7. 现场排查从一段报错到定位根因7.1 异常与现象速查表排查这件事经验的价值主要体现在“看到这个现象先怀疑什么”。我整理了一份自己常用的速查表都是这些年踩出来的。现象优先怀疑验证方式ConcurrentModificationException遍历集合时结构性修改检查循环里有没有add/removeNullPointerException找不到源头链式调用中某环为 null拆开链式调用逐段打日志内存持续上涨不回落集合只增不减、缓存没淘汰导出堆看对象数量排名CPU 打满但 QPS 不高死循环、正则回溯、频繁 GC抓线程栈看热点方法接口偶发超时下游慢、连接池不够、锁竞争分段计时定位耗时环节启动报循环依赖构造器注入形成的环看报错里的 bean 链路ConcurrentModificationException这个特别值得说。它不是“并发”导致的单线程也会抛。ArrayList内部维护一个modCount迭代过程中只要结构被改动增加、删除modCount就和迭代器记录的期望值对不上直接 fail-fast。正确做法是用迭代器的remove方法或者用removeIf。7.2 我的四步定位法遇到问题我固定走四步顺序不乱。第一步稳定复现。不能复现的问题等于没找到问题。如果本地复现不了就去找触发条件特定数据、特定并发量、特定时间点。我遇到过只在整点出现的超时最后发现是定时任务和业务请求抢同一个连接池。第二步缩小范围。二分法砍代码注释掉一半看还出不出。日志也是同理在关键节点打时间戳看耗时集中在哪一段。这一步最枯燥但不能跳。第三步提出假设并验证。别一次改五个地方再跑那样即使好了你也不知道是哪个改动起的作用。一次只改一个变量改完立刻验证。第四步回写记录。解决完把根因、验证方式、修正方案记下来。我有个毛病是同一个坑踩两次后来强迫自己每次排查完写三行笔记情况好了很多。7.3 手上要常备的几个工具命令不用装任何额外东西JDK 自带的几个命令就能解决大部分现场问题。# 看 Java 进程号和启动参数 jps -lvm # 抓线程栈连续抓三次看哪个线程一直停在同一个位置 jstack pid stack1.txt jstack pid stack2.txt # 看堆内存分布和各代使用情况 jmap -heap pid # 导出堆快照配合分析工具看对象占用 jmap -dump:formatb,fileheap.hprof pid # 看 GC 频率和停顿 jstat -gcutil pid 1000jstack连抓三次这个技巧特别实用。单次线程栈只能看到瞬间状态连抓三次对比一直卡在同一个方法上的线程就是嫌疑对象。死锁、长时间等待、线程池打满基本都能这么看出来。jstat的输出重点看两个老年代使用率涨得快不快以及 Full GC 的次数和耗时。如果老年代几分钟就涨满、Full GC 频繁但回收效果差基本可以确定有对象被长期持有往缓存或者静态集合的方向查。8. 回答别人问题时我自己养成的几个习惯8.1 先问版本再谈结论Java 的版本差异比很多人想象的大。Optional是 8 才有的var是 10 才有的switch表达式是 14 才转正的虚拟线程是 21 才正式发布的。同一个问题在 8 和 17 上答案可能完全不同。我见过有人拿着 8 的项目问“为什么 record 不能用”也见过有人在新版本上纠结HashMap的扩容细节而新版本已经改过实现。所以我现在看到提问第一反应是先确认版本版本不对后面所有分析都是浪费。框架版本同理。有的行为在某个小版本里改过升级之后语义就变了。严谨的做法是把版本号写进问题描述里这也是我建议提问的人养成的习惯。8.2 把“能跑”和“正确”分开看这是我这些年最深的体会。一段代码能跑通、能出正确结果和它在所有情况下都正确是两码事。前面提到的Integer用比较金额小的时候能跑SimpleDateFormat单线程用能跑事务在没异常的情况下能跑。这些都是“能跑但不正确”。养成区分这两者的习惯之后我审查代码的角度变了。以前看“逻辑对不对”现在还会看“在并发下、在大数据量下、在异常路径下它还对吗”。这三个问题问出来能提前发现一大半隐患。最后分享一个我自己在用的笨办法每次解决完一个社区问题我会把根因用一句话写下来攒在一个文档里。写了两年多现在遇到新问题翻一翻旧记录经常能找到结构相似的案例。排查能力这东西靠的不是记性好是把踩过的坑整理成了可以复用的判断路径。 
长河君 · 2026/10/31 10:19:26 · 阅读 1.2k Java高频坑排查地图：从语义、并发到框架的定位顺序
社区问答区里泡久了你会发现 Java 板块的提问翻来覆去就那么几类一段代码跑出来的结果和预期不一样、线上偶发一个说不清的异常、某个注解加了却像没加。标题起得五花八门点进去看根子大多落在几个老地方——对象语义没吃透、共享可变状态没管住、容器和框架的默认行为没搞清楚。这些问题单看都很碎但它们背后的认知缺口高度重合所以我一直想找个机会把它们按层拆一遍。这篇东西不是面试题合集也不是 API 手册。它解决的是“看到一段有问题的 Java 代码我该从哪一层开始怀疑”这个问题。适合工作一到三年的开发也适合带新人的同学拿去当排查思路的参照。读完之后你至少能做到两件事别人贴一段代码问为什么不对你能在三分钟内判断问题出在语义层、并发层还是框架层自己写代码时能提前避开那批最容易踩的坑。1. 这些问题为什么值得单独拎出来讲1.1 一个提问背后往往藏着三层认知缺口我观察过大量提问帖发现一个规律提问者描述的“现象”和他真正的“问题”经常不是一回事。有人问“为什么我的 HashSet 里出现了两个一模一样的对象”现象是集合行为异常真正的问题是equals和hashCode只重写了一半。有人问“为什么加了锁还是超卖”现象是并发不安全真正的问题是他锁的对象每次都在变。再往下挖还有一层他根本不知道自己不知道什么。比如很多人从没意识到 Java 的整数装箱是有缓存的比较两个Integer有时候是 true 有时候是 false于是他把这当成“玄学”绕着走而不是去搞明白规则。这三层缺口对应的解决方式完全不同。现象层只需要改代码语义层需要补概念认知层需要重建判断习惯。如果只按现象给答案提问的人下个月还会拿一个变形的问题回来问。1.2 这类内容真正的价值在“判断顺序”而不是“标准答案”我不太喜欢直接给答案。Java 的很多问题有多个“正确”答案取决于版本、取决于使用场景、取决于你到底想要什么语义。比如问“字符串拼接用还是StringBuilder”答案是“看你在哪拼”。单条表达式里编译器自己就优化了循环里手写就是自找麻烦。真正有价值的是判断顺序先确认事实再定位层次最后才谈方案。这个顺序错了后面全是白费功夫。我见过太多人一上来就怀疑框架有 bug查了三个小时最后发现是自己类没被 Spring 管理。所以下面我按“语义、并发、集合性能、框架、排查”这五层来组织每层挑几个被问得最多的问题把现象、根因、验证方法、修正方案都摆出来。你可以把它当成一份排查地图遇到新问题的时候先定位它在哪一层再往下查。2. 先给问题分个层把“报错”翻译成“知识点”2.1 四类高频问题的共同特征我把社区里反复出现的 Java 问题归成四类每类的特征很鲜明。语义类问题的特征是“结果确定但不符合直觉”。同样的代码跑一百次都是一样的错误结果这恰恰说明它不是偶发 bug而是你对语言规则的理解有偏差。典型代表是与equals的区别、基本类型与包装类型的转换、重载方法的解析顺序。并发类问题的特征是“偶发、难复现、加日志就消失”。这类问题最耗时间因为你在本机跑一万次都正常上线之后一天出一次。典型代表是共享SimpleDateFormat、非原子自增、可见性问题。集合与性能类问题的特征是“功能对但慢或者内存涨”。这类问题不会立刻暴露往往在数据量上去之后才显现。典型代表是循环里拼字符串、集合没预设容量、无界队列堆积。框架类问题的特征是“配置看起来没问题但就是不生效”。这类问题最容易被误判为框架 bug。典型代表是事务注解失效、异步注解失效、循环依赖启动报错。分清这四类你就知道该往哪个方向找证据。语义类去看代码本身并发类去看共享状态性能类去看数据量和调用频次框架类去看代理和容器管理。2.2 我常用的分类框架与判断顺序具体怎么判断我做了一张对照表遇到问题时按“现象关键词”先去匹配能省掉大量试错时间。现象关键词大概率所属层第一件该确认的事常用验证手段结果稳定复现、逻辑看着没问题语义层涉及的类型是基本类型还是包装类型打印getClass()和实际值偶发、并发量上来才出现并发层有没有共享的可变对象压测复现、加线程数单次正常、批量处理变慢性能层循环内有没有重复创建大对象打时间戳分段计时注解加了但行为没变框架层当前调用是否经过代理打印this.getClass()看是否被代理判断顺序上我的习惯是“先排除简单解释”。如果一个问题是稳定复现的那它百分之百是代码逻辑或语言规则问题跟并发、跟框架都没关系别浪费时间去看源码。反过来如果一个问题只在压力下出现先别急着改逻辑先确认是不是共享状态。这里有个很多人会忽略的细节代理对象的类名和原始类名不一样。你在被 Spring 管理的 bean 里打印this.getClass().getName()如果看到类似XxxService$$EnhancerBySpringCGLIB$$...这样的名字说明它被代理了如果是干净的类名说明某些代理机制没生效事务、异步这些依赖代理的功能自然也失效了。这一招在排查注解失效时特别好使。提示判断代理是否生效比翻文档快十倍。打印一次类名胜过查半小时配置。3. 语义层那些“看起来对、跑起来错”的坑3.1 equals 与 hashCode 的契约破坏一半会怎样这是社区里被问得最多的问题没有之一。提问形式通常是“我往HashSet里加了两个内容一样的对象为什么 size 是 2”根本原因是 Java 对equals和hashCode有一条明确契约如果两个对象equals返回 true它们的hashCode必须相等。如果你只重写了equals两个内容相同的对象会有不同的哈希值落到哈希表的不同桶里压根不会触发equals比较于是“重复”就被放进去了。public class User { private String name; private int age; public User(String name, int age) { this.name name; this.age age; } Override public boolean equals(Object o) { if (this o) return true; if (!(o instanceof User)) return false; User user (User) o; return age user.age Objects.equals(name, user.name); } // 故意不重写 hashCode public static void main(String[] args) { SetUser set new HashSet(); set.add(new User(A, 20)); set.add(new User(A, 20)); System.out.println(set.size()); // 输出 2不是 1 } }哈希表的查找逻辑是两步先用hashCode定位桶再在桶里用equals逐个比较。第一步定位错了后面的比较根本不会发生。所以正确的做法是两个一起重写且参与计算的字段要一致——equals里用了name和agehashCode里也得用这两个。还有一个更隐蔽的坑对象作为 key 之后修改了参与哈希计算的字段。比如你把User放进HashMap之后改了name这个 key 的哈希值变了再用它去get就找不到了。这不是HashMap的 bug是你违反了自己声明的契约。我在实际项目里碰到过一次排查了整整一个下午最后发现是缓存层复用了同一个可变对象当 key。提示凡是进集合当 key、或者进Set去重的对象尽量设计成不可变对象。改不了就不会有哈希漂移。3.2 Integer 缓存与 的关系第二个高频问题“为什么Integer a 127; Integer b 127;打印 true换成 128 就变成 false 了”这属于典型的语义层认知缺口很多人把它当成编译器抽风。实际规则很清晰Integer的自动装箱走的是Integer.valueOf(int)这个方法内部维护了一个缓存数组默认范围是 -128 到 127。落在这个范围内的整数直接返回缓存对象所以两次装箱拿到的是同一个引用比较自然为 true。Integer a 127; Integer b 127; System.out.println(a b); // true命中缓存 Integer c 128; Integer d 128; System.out.println(c d); // false超出缓存各自 new Integer e new Integer(127); System.out.println(a e); // falsenew 一定创建新对象 System.out.println(a.equals(e)); // trueequals 比的是值缓存上限默认是 127可以通过启动参数-XX:AutoBoxCacheMax1000调整但它调的是上限下限 -128 是写死的。这个问题在业务代码里的实际危害比你想象的大。我见过有人用比较订单金额的Integer字段测试环境金额小全部命中缓存跑得飞快生产环境订单一过千判断集体失效变成了“金额不同的两笔订单被判为相等”。这种 bug 不报错、不抛异常只是默默算错。结论很干脆包装类型的值比较一律用equals或者先转成基本类型再比。别依赖缓存范围那是实现细节不是语义保证。3.3 i 的原子性错觉与 volatile 的边界“我加了 volatile为什么自增还是会少”这个问题的提问频率仅次于前面那个。先看代码public class Counter { private volatile int count 0; public void increment() { count; // 这不是一个原子操作 } }count在字节码层面是四步读取字段值、压入常量 1、执行加法、写回字段。volatile保证的是可见性和禁止重排序不保证这四步作为整体不被打断。线程 A 读到 5还没写回线程 B 也读到 5两个线程各自加一写回最终结果是 6 而不是 7。解决办法有三个层次的取舍。最低成本是加锁synchronized或者ReentrantLock正确但吞吐差。第二种是用AtomicInteger的incrementAndGet()基于 CAS 循环无锁且正确适合竞争不激烈的场景。第三种是高竞争场景用LongAdder把热点分散到多个单元格上最后求和吞吐更高但只能拿到最终结果中途读取的值不精确。private final AtomicInteger counter new AtomicInteger(0); public void increment() { counter.incrementAndGet(); }注意volatile的正确用途是“一个线程写、多个线程读”的状态标记比如volatile boolean running。凡是涉及“读—改—写”复合操作的它都顶不住。这里还牵出一个常被忽略的点volatile的可见性保证是有前提的它保证的是对这个变量的读写不会被缓存到线程本地但不保证复合操作的原子性。这两个概念经常被混为一谈导致有人觉得“加了 volatile 就线程安全了”。真要建立正确认知得把 Java 内存模型里“原子性、可见性、有序性”这三件事分开理解缺一不可。4. 并发层共享可变状态是万恶之源4.1 SimpleDateFormat 出错的真实原因这个坑几乎每个团队都踩过。现象是日期格式化偶尔出现乱码、年份变成奇怪的数字或者直接抛NumberFormatException。而且诡异的是本地单线程测试永远正常。根因在于SimpleDateFormat内部持有一个Calendar对象作为可变状态format和parse方法都会先 clear 再 set 这个 Calendar。多个线程共用一个实例时A 线程刚 set 完年份B 线程把整个 Calendar 清了A 再去读就拿到了脏数据。解决办法按推荐程度排序。第一选择是换成DateTimeFormatter它是不可变且线程安全的配合LocalDateTime、LocalDate使用API 也更清晰private static final DateTimeFormatter FORMATTER DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); public String format(LocalDateTime time) { return FORMATTER.format(time); } public LocalDateTime parse(String text) { return LocalDateTime.parse(text, FORMATTER); }如果因为历史原因必须用SimpleDateFormat那就用ThreadLocal每个线程一份或者每次方法内 new 一个——后者在小流量下完全没问题别为了省一个对象搞出并发 bug。至于synchronized包一层正确但会把这行代码变成串行点高频调用下得不偿失。我在实际项目里做过一次统计一个中等流量的接口每次请求 new 一个DateTimeFormatter是完全可接受的因为它本身就是不可变对象构造开销很小。真正贵的是SimpleDateFormat那种带内部状态的类。所以选型的时候优先看“是否可变”而不是“是否 new”。4.2 线程池参数该怎么算队列怎么选线程池的问题在社区里分两派一派问参数怎么配一派问为什么不生效。先解决配参数。参数计算有个常用的经验公式。设 CPU 核数为 NCPU 密集型任务大量计算、少量等待核心线程数设为 N 1。多出来的一个用于在某个线程偶发缺页或短暂阻塞时顶上。IO 密集型任务大量数据库查询、远程调用核心线程数设为 N × (1 平均等待时间 / 平均计算时间)。这个公式的本质是让 CPU 在等待期间有活可干。举个例子8 核机器任务平均计算 10 毫秒、等待 90 毫秒那么理想线程数是 8 × (1 9) 80。当然这是理论上限实际还要考虑下游数据库能扛多少并发别把压力全推给数据库。比参数更容易出错的是队列的选择。很多人用默认的Executors.newFixedThreadPool它内部是无界队列任务堆积起来永远不会触发拒绝策略内存一路涨到 OOM。正确的做法是显式指定有界队列比如new ArrayBlockingQueue(200)队列满了触发拒绝策略。拒绝策略我优先选CallerRunsPolicy它让提交任务的线程自己执行形成天然的背压——线程池忙不过来时上游会被拖慢而不是把任务丢掉或者抛异常。这在 web 场景下比AbortPolicy温和得多。还有一个执行顺序的细节很多人搞反了线程池接到任务后先看核心线程数满没满没满就新建线程满了就进队列队列满了才把线程数扩到最大最大也满了才走拒绝策略。也就是说队列容量设得太大最大线程数永远用不上。这个顺序搞明白配参数的时候就不会盲目调大队列。4.3 双重检查锁为什么少不得 volatile单例模式的双重检查写法是并发层里被讨论最多的一段代码public class Singleton { private static volatile Singleton instance; public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }为什么必须加volatile因为instance new Singleton()在字节码层面分三步分配内存、初始化对象、把引用赋给变量。步骤二和步骤三在某些处理器上可能重排序。如果发生重排另一个线程在第一次判空时可能看到一个非 null 但还没初始化完成的对象然后拿着它去用拿到的字段全是默认值。volatile在这里的作用是禁止这个重排序保证“初始化完成”一定发生在“引用可见”之前。少了这个关键字代码在单线程下永远正确在多线程下概率性出错——最难查的那一类。顺带说一句实际项目里我更推荐静态内部类写法靠类加载机制保证线程安全代码还更短public class Singleton { private Singleton() {} private static class Holder { private static final Singleton INSTANCE new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }类加载是线程安全的INSTANCE在类初始化时创建天然延迟加载。除非你需要传参构造否则没理由手写双重检查。5. 集合与性能别让容器替你的疏忽买单5.1 ArrayList 扩容的代价与预设容量ArrayList的默认初始容量是 10但这个数组是在第一次add时才分配的构造时只是给了一个共享的空数组。之后每次容量不够按oldCapacity (oldCapacity 1)扩容也就是 1.5 倍然后调用Arrays.copyOf把老数据整体复制过去。单次扩容不贵但累积起来很可观。假设你要装 100 万个元素从 10 开始一路 1.5 倍扩上去中间会经历二十多次扩容累计复制的元素数量大约是最终规模的两倍多。如果预先知道规模直接new ArrayList(1000000)一次分配到位省掉所有复制。// 不推荐默认容量反复扩容 ListOrder list new ArrayList(); for (Order o : orders) { list.add(o); } // 推荐已知规模直接指定 ListOrder list new ArrayList(orders.size());还有一个反直觉的点ArrayList删除元素比添加贵得多。remove(i)之后要把后面所有元素往前挪一位是 O(n) 操作。如果在循环里做删除用迭代器的remove或者干脆倒序遍历避免索引错位。这个坑我在写批量处理逻辑时踩过删除条件命中率高的时候性能直接从秒级掉到分钟级。5.2 HashMap 的 8 和 64 到底在防什么面试常问“HashMap的树化阈值为什么是 8”很多人背了答案但没理解。这里说清楚。HashMap在链表长度达到 8 且数组容量至少 64 时会把链表转成红黑树。选 8 这个数不是拍脑袋是基于泊松分布的统计结果在哈希函数分布均匀的理想情况下一个桶里链表长度达到 8 的概率大约是千万分之六。也就是说正常情况下你几乎遇不到树化一旦遇到说明哈希分布出了问题比如大量 key 的hashCode冲突这时候需要红黑树把查询从 O(n) 拉回 O(log n)。MIN_TREEIFY_CAPACITY 64这个条件更值得注意。当数组容量还小的时候即使链表长了也优先扩容而不是树化——扩容会把元素重新打散到更多桶里可能冲突就自然消失了。扩容比维护红黑树便宜。所以真实的判断顺序是链表长度到 8先看数组容量够不够 64不够就扩容够了才树化。退化阈值是 6不是 8中间留了一个缓冲防止在 7、8 之间反复横跳来回转换结构。实际使用上的建议只有一条能预估规模就指定初始容量。比如确定要放 1000 个元素按负载因子 0.75 反推初始容量设 1024 就够能避免多次扩容。但别设得过于精确扩容的触发条件是size capacity * 0.75卡在边界上很容易多扩一次。5.3 循环里拼字符串为什么慢得离谱这个问题在社区里出现频率极高代码通常长这样String result ; for (int i 0; i 10000; i) { result i; }看起来没什么实际复杂度是 O(n²)。因为String是不可变的每次都会创建一个新的StringBuilder、append 进去、再toString()生成新字符串上一轮的字符串变成垃圾。一万次循环意味着创建一万个StringBuilder和一万个中间字符串GC 压力巨大。StringBuilder sb new StringBuilder(10000 * 5); for (int i 0; i 10000; i) { sb.append(i); } String result sb.toString();这里我还想补一个容易被忽略的细节编译器确实会优化字符串拼接但只在单条表达式内。像a b c这样的单句编译器会合成一次StringBuilder操作。但循环里的涉及跨迭代的状态编译器不会帮你提到循环外面只能老老实实每次都 new。StringBuilder和StringBuffer的选择也很简单单线程用前者需要线程安全用后者。但说实话我极少见到真正需要StringBuffer的场景因为字符串拼接几乎总在方法内部的局部变量上进行天然线程隔离。把共享的StringBuilder当成员变量用才是真正该警惕的写法。6. 框架层注解不生效的几种典型姿势6.1 事务失效的六种场景与自检清单“我加了Transactional为什么还是脏数据”这个问题在问答区几乎每周都有人问。事务失效的原因很集中我列成清单遇到问题逐条排查就行。场景失效原因修正方式同类内部方法直接调用走的是this不经过代理拆到另一个 bean或注入自身代理方法不是 public早期版本代理无法拦截非 public 方法改成 public异常被自己 catch 了容器感知不到异常不会回滚别吞异常或手动setRollbackOnly抛的是受检异常默认只对RuntimeException和Error回滚加rollbackFor Exception.class在新线程里调用事务绑定在线程上下文上跨线程丢失别在异步线程里指望外层事务类没被容器管理自己new出来的对象没有代理交给容器管理第一条是最容易中招的。this.saveOrder()这种调用看起来是“调了自己的方法”实际上绕过了代理对象事务拦截器根本没机会介入。解决办法要么把方法挪到另一个 bean 里要么注入自己的代理引用注意可能有循环依赖问题需要配Lazy。第四条也很典型。很多团队封装了统一的业务异常继承自Exception抛出去之后事务不回滚数据已经写了一半。这类问题在测试环境很难发现因为测试用例通常不校验数据一致性。提示排查事务问题第一步永远是确认当前对象是不是代理对象。打印类名一秒见分晓。6.2 循环依赖为什么能解决又为什么有时解决不了Spring 用三级缓存解决单例 bean 的循环依赖一级缓存放完整对象二级缓存放早期暴露的对象三级缓存放对象工厂。A 依赖 B、B 依赖 A 时A 实例化后先把工厂放进三级缓存去填充 B 的属性B 需要 A 时从三级缓存拿到早期引用B 完成初始化A 再完成初始化。但有两种情况它解决不了。第一种是构造器注入的循环依赖因为对象还没实例化完压根没有引用可以提前暴露。第二种是原型作用域的循环依赖容器不缓存原型 bean。实际项目里循环依赖能解决不代表应该存在。我见过一个 service 里注入了七八个其他 service互相之间还打转最后靠三级缓存勉强启动。这种设计一旦有改动就容易炸。合理的做法是把公共逻辑下沉到更细的组件或者用事件机制解耦。真遇到启动报错第一反应应该是“我的依赖关系画错了吗”而不是“怎么把这个错绕过去”。6.3 Async 静默失败的排查路径Async的问题特点是不报错、不生效、毫无提示。方法照常返回只是变成同步执行了。排查路径我固定成三步。第一看注解所在的方法是不是被同类内部调用如果是跟事务失效是同一个原因没走代理。第二看启动类或配置类上有没有开EnableAsync这个漏了的情况非常多因为编译期不报错。第三看有没有自定义线程池不配的话默认用SimpleAsyncTaskExecutor每次调用新建线程且不复用在高并发下会直接把线程数打爆。Configuration EnableAsync public class AsyncConfig { Bean(bizExecutor) public Executor bizExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(200); executor.setThreadNamePrefix(biz-async-); executor.setRejectedExecutionHandler( new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }另外注意返回值。异步方法返回void时异常会被吞掉你连出错都不知道返回Future或CompletableFuture才能拿到异常。生产环境我建议一律返回CompletableFuture至少留个可以捕获异常的口子。7. 现场排查从一段报错到定位根因7.1 异常与现象速查表排查这件事经验的价值主要体现在“看到这个现象先怀疑什么”。我整理了一份自己常用的速查表都是这些年踩出来的。现象优先怀疑验证方式ConcurrentModificationException遍历集合时结构性修改检查循环里有没有add/removeNullPointerException找不到源头链式调用中某环为 null拆开链式调用逐段打日志内存持续上涨不回落集合只增不减、缓存没淘汰导出堆看对象数量排名CPU 打满但 QPS 不高死循环、正则回溯、频繁 GC抓线程栈看热点方法接口偶发超时下游慢、连接池不够、锁竞争分段计时定位耗时环节启动报循环依赖构造器注入形成的环看报错里的 bean 链路ConcurrentModificationException这个特别值得说。它不是“并发”导致的单线程也会抛。ArrayList内部维护一个modCount迭代过程中只要结构被改动增加、删除modCount就和迭代器记录的期望值对不上直接 fail-fast。正确做法是用迭代器的remove方法或者用removeIf。7.2 我的四步定位法遇到问题我固定走四步顺序不乱。第一步稳定复现。不能复现的问题等于没找到问题。如果本地复现不了就去找触发条件特定数据、特定并发量、特定时间点。我遇到过只在整点出现的超时最后发现是定时任务和业务请求抢同一个连接池。第二步缩小范围。二分法砍代码注释掉一半看还出不出。日志也是同理在关键节点打时间戳看耗时集中在哪一段。这一步最枯燥但不能跳。第三步提出假设并验证。别一次改五个地方再跑那样即使好了你也不知道是哪个改动起的作用。一次只改一个变量改完立刻验证。第四步回写记录。解决完把根因、验证方式、修正方案记下来。我有个毛病是同一个坑踩两次后来强迫自己每次排查完写三行笔记情况好了很多。7.3 手上要常备的几个工具命令不用装任何额外东西JDK 自带的几个命令就能解决大部分现场问题。# 看 Java 进程号和启动参数 jps -lvm # 抓线程栈连续抓三次看哪个线程一直停在同一个位置 jstack pid stack1.txt jstack pid stack2.txt # 看堆内存分布和各代使用情况 jmap -heap pid # 导出堆快照配合分析工具看对象占用 jmap -dump:formatb,fileheap.hprof pid # 看 GC 频率和停顿 jstat -gcutil pid 1000jstack连抓三次这个技巧特别实用。单次线程栈只能看到瞬间状态连抓三次对比一直卡在同一个方法上的线程就是嫌疑对象。死锁、长时间等待、线程池打满基本都能这么看出来。jstat的输出重点看两个老年代使用率涨得快不快以及 Full GC 的次数和耗时。如果老年代几分钟就涨满、Full GC 频繁但回收效果差基本可以确定有对象被长期持有往缓存或者静态集合的方向查。8. 回答别人问题时我自己养成的几个习惯8.1 先问版本再谈结论Java 的版本差异比很多人想象的大。Optional是 8 才有的var是 10 才有的switch表达式是 14 才转正的虚拟线程是 21 才正式发布的。同一个问题在 8 和 17 上答案可能完全不同。我见过有人拿着 8 的项目问“为什么 record 不能用”也见过有人在新版本上纠结HashMap的扩容细节而新版本已经改过实现。所以我现在看到提问第一反应是先确认版本版本不对后面所有分析都是浪费。框架版本同理。有的行为在某个小版本里改过升级之后语义就变了。严谨的做法是把版本号写进问题描述里这也是我建议提问的人养成的习惯。8.2 把“能跑”和“正确”分开看这是我这些年最深的体会。一段代码能跑通、能出正确结果和它在所有情况下都正确是两码事。前面提到的Integer用比较金额小的时候能跑SimpleDateFormat单线程用能跑事务在没异常的情况下能跑。这些都是“能跑但不正确”。养成区分这两者的习惯之后我审查代码的角度变了。以前看“逻辑对不对”现在还会看“在并发下、在大数据量下、在异常路径下它还对吗”。这三个问题问出来能提前发现一大半隐患。最后分享一个我自己在用的笨办法每次解决完一个社区问题我会把根因用一句话写下来攒在一个文档里。写了两年多现在遇到新问题翻一翻旧记录经常能找到结构相似的案例。排查能力这东西靠的不是记性好是把踩过的坑整理成了可以复用的判断路径。