凌晨三点，你被电话叫醒——线上接口超时，用户无法下单。你打开日志，看到一行NullPointerException，指向一个你两周前刚提交的方法。你揉了揉眼睛，发现那个对象明明在上一行已经做了判空。为什么还是空？你翻出代码，看到了熟悉的if (obj != null) { ... }，但忽略了obj其实是个被静态工厂方法返回的“空壳”。这种场景，每个Java开发者都经历过，却很少有人在写代码的那一刻停下来想一想：真正让你凌晨起床的，从来不是那些复杂的设计模式，而是那些被你随手写下的、看似无害的代码习惯。
你不会记得自己有多少次在catch块里写e.printStackTrace()，也不会记得多少次用==去比较两个Integer。这些细节就像鞋里的沙粒，不磨破脚的时候，你根本感觉不到它们存在。但正是这些沙粒，在某个高并发时刻、某个数据迁移的夜晚、某个对象复用的瞬间，集体爆发，把系统拽入深渊。本文不聊架构，不谈框架，只聚焦那些被大多数教程和面试题忽略的代码细节——它们才是决定你代码能否在真实环境中活过三个月的关键。
空指针不是偶然，是习惯的必然
Java世界里最经典的笑话：“空指针不是bug，是日常。”但你真的认真分析过每一个NPE的根因吗？很多时候，NPE并不来自外部接口传参，而来自你自己返回了一个null。你写了一个方法叫getUserByName，查不到时返回null，调用方忘了判空，直接.getAddress()。于是NPE在远离数据源的地方炸开。方法签名里写满“可能为空”的暗示，却从不显式表达，这是Java代码中最大的隐性契约漏洞。
我建议你养成一个习惯：永远不要让一个公开方法返回null作为“无结果”的表示。你可以返回空集合、空Optional，或者抛出一个语义明确的异常。空集合的代价微乎其微，但能消灭一整个类别的NPE。但如果有人告诉你“我用Optional就一定安全”，那又掉进了另一个坑。Optional本身是对象，如果你直接返回null作为Optional的返回值，那比返回null更危险——因为调用方会放心地.orElse(...)，结果NPE提前发生在Optional上。Optional不是免死金牌，它只是把“谁负责处理缺失”这个问题从调用方移到了提供方。
再看一个高频习惯：用==比较两个Integer。你以为所有Integer都是[-128,127]吗？超过这个范围，==比较的是引用地址，而不是数值。你可能会说“我写过一次就记住了”，但真正危险的是那些藏在Bean转换、工具类里的==，它们不会在测试时触发，只会在大数值出现的生产环境里给你颜色看。永远用Objects.equals()或.equals()比较包装类型，这是一个不需要思考的本能。
异常吞噬——最安静的炸弹
你有没有见过这样的代码：
try { // 业务逻辑 } catch (Exception e) { // 忽略 }
或者更“高级”一点：
try { // 业务逻辑 } catch (Exception e) { log.error("something went wrong", e); }
第一段代码叫“沉默的失败”，第二段代码叫“自欺欺人的成功”。你以为打了日志就万事大吉，但日志只出现在ERROR级别，监控不告警，调用方拿不到任何反馈，数据悄悄错了，用户默默吃亏。捕获异常却不重新抛出、不回滚事务、不向上传递，远比不捕获更可怕——它把错误变成了“假成功”。你可能会辩解说“这是异步任务，失败了不影响主流程”。那请你想清楚：异步任务里的失败影响多少下游依赖？如果影响仅限一条记录，你是否至少该有补偿机制？没有补偿的catch只是把炸弹埋得更深。
更隐蔽的习惯是“catch后吞掉异常，却返回一个默认值”。比如从Redis取缓存，连接失败时catch (Exception e) { return null; }。这个null会导致DB被穿透，甚至引发雪崩。任何降级逻辑都必须有明确的降级记录和指标埋点，否则你就是在生产环境里玩俄罗斯轮盘。正确的姿势是：要么让异常继续向上抛，由全局处理器统一兜底；要么在catch里记录一个高等级日志，并加上告警标签，同时返回一个“可区分”的降级结果，而不是静默的 null。
日期时间处理的隐性时区监狱
Java 8以后，SimpleDateFormat被官方标记为“不推荐使用”，但你的代码库里一定还有它的影子。除了线程不安全（这个大家都知道），它还有另一个更隐蔽的坑：隐式时区。你在服务器上运行，服务器默认时区是UTC还是GMT+8，决定了一个Date打印出来的样子。但当你把Date转成字符串存到MySQL的DATETIME字段时，JDBC驱动又会用JVM默认时区转换。于是你发现，测试环境数据正常，生产环境数据少了8小时。时间不会说谎，但时区会让你说出错误的时间。
真正的习惯应该是：在所有涉及时间传递的边界，强制使用UTC，并显式指定时区。比如LocalDateTime不携带时区，但它适合做业务时间的“本地表达”；如果你要存储一个全局事件的时间戳，请使用Instant或带时区的OffsetDateTime。同时，永远不要用System.currentTimeMillis()去“格式化”成yyyy-MM-dd来比较日期——那不是比较，那是转换时区的赌局。另一个细节是SimpleDateFormat的替代品DateTimeFormatter，它虽然是线程安全的，但如果你用.withZone(ZoneId.systemDefault())，你仍然把命运交给了服务器。凡是不显式写时区的日期代码，都是在给未来的维护者挖坑。
equals与hashCode的契约，比你想的更严肃
很多Java开发者能背出equals和hashCode的契约，但写起来依然随性。最常见的错法是：equals用instanceof判断类型，hashCode却只返回一个常量。这会导致什么？把所有对象都散列到同一个桶，HashMap变成链表，查询效率从O(1)跌到O(n)。你可能会说“我的对象只有一个实例”，但没人能在写代码时保证未来不会把它放进Set或者作为Map的key。hashCode的分布质量，决定了你代码在集合里的生存速度。
另一个细节是equals中的类型判断。用getClass()和用instanceof有本质区别。如果你的父类重写了equals，子类继承后，instanceof会让两个不同子类的实例“相等”，但它们可能拥有不同的字段。反过来，如果你用getClass()，子类继承父类的equals就无法比较了（因为类型不同）。正确做法是：在重写equals时，先this == o，再o == null || getClass() != o.getClass()，最后比较关键字段。而hashCode必须保证：equals相等的对象，hashCode一定相等；equals不相等的对象，hashCode尽量不相等。不要偷懒用常量，更不要用hashCode()返回随机数。
还有一个容易被忽略的细节：equals方法里比较字段时，如果字段是基本类型用==，如果是引用类型用Objects.equals()。但很多人会直接写field == other.field，然后两个字符串对象地址不同，equals永远返回false。你在写equals时对字段比较方式的疏忽，就是下一次集合查询失败的伏笔。
字符串拼接的性能与语义陷阱
“字符串拼接用StringBuilder”是老生常谈，但很多人在循环里仍然写str += "..."。现代Java编译器（JDK 9+）会对简单拼接做优化，但在循环体内，它可能会生成大量中间对象。你以为编译器帮你优化了，实际上它只是在每次循环里创建了新的StringBuilder。更隐蔽的问题来自split()方法——它接受的是正则表达式，而不是普通字符串。你想用"."分割IP地址，结果得到空数组。每个Java开发者都该把split、replaceAll、matches这几个方法的名字记成“正则方法”，而不是“字符串方法”。
另一个习惯是使用String.format拼接日志。日志框架中的慢不仅仅是字符串拼接本身，还有参数的计算。如果你写log.debug("user: " + user.getFullName())，即使日志级别是INFO，开头的字符串拼接也会执行。正确做法是使用占位符：log.debug("user: {}", user.getFullName())，这样只有在需要输出时才会调用toString。日志级别判断不是让你的代码变慢的原因，真正的原因是你无条件地构造了消息。此外，用String.join或Collectors.joining替代手写循环拼接，阅读性更好，性能也不差。但注意：如果你在循环里不断创建StringBuilder实例，那和直接加号没什么区别。一个只属于循环体外的StringBuilder，才是你真正要养的宠物。
资源关闭的谎言——try-with-resources不是万能的
Java 7引入了自动资源管理，但很多人在使用时有错觉：认为只要写了try-with-resources，资源就一定被关闭。实际上，如果你的资源对象在构造函数里抛异常，那么外层代码拿到的可能是一个未完全初始化的资源，而它压根不会被关闭。更常见的陷阱是：在close()方法中本身会抛异常。如果你用try-with-resources，关闭时的异常会被正常捕获，但如果你在同一段代码里先操作资源后关闭，关闭异常可能会覆盖掉业务异常。资源关闭的正确顺序是：先处理完后置的异常，再让资源关闭异常作为补充，而不是反过来。
另一个资源细节是：InputStream、OutputStream、Connection都可能持有底层系统资源。你在finally块里手动close()，但忘了关掉BufferedReader包装的底层流——没关系，关闭包装流会关闭底层流。但如果你先关了底层流，再关包装流，包装流的close()会抛IOException。记住一条铁律：关闭资源要沿着创建顺序的反向，且只关最外层的包装。还有那些实现了AutoCloseable但内部是静态共享连接池的对象（比如某些客户端），频繁关闭可能导致连接池耗尽。你需要辨别“真正的资源”和“逻辑上的资源”，不要一刀切地关闭。
并发下的“原子”幻想
i++不是原子操作，这一句话说过无数遍，但依然有人在不同线程里对同一个int字段自增，然后期待结果是正确的。你可能知道volatile不能保证复合操作的原子性，但你用AtomicInteger就安全了吗？如果你做的是“先检查后操作”（例如if (counter.get() < LIMIT) { counter.incrementAndGet(); }），这个判断加自增就不是原子的——两个线程可能同时通过检查，然后自增两次。原子类只保证单次操作原子，不保证复合操作原子。复合操作需要synchronized或Lock，或者使用ConcurrentHashMap的compute等原子方法。
另一个并发细节是：ConcurrentHashMap的get和put是线程安全的，但get之后put之间可能发生其他线程的修改。所以“先get再put”的缓存逻辑，很可能覆盖掉别人的更新。使用computeIfAbsent或putIfAbsent，才能把复合操作变成原子操作。但即便用了putIfAbsent，你还需要考虑“如果value已经存在，但它是过期的，怎么办？”——这又回到了“锁的粒度”问题。真正的并发安全不是靠某个类声明了线程安全，而是靠你对每个操作序列的理解。
还有synchronized锁对象的陷阱。很多人喜欢给方法加synchronized，但如果你锁的是this，而外部代码又用不同的锁，那么锁就形同虚设。正确地锁住一个专门为并发控制而生的最终字段，例如private final Object lock = new Object();，才能让锁的边界清晰。而锁的粒度过大，会导致吞吐量下降；粒度太小，又容易死锁。这里没有银弹，只有靠你反复推演并发时序图。
内存泄漏——看不见的握手
Java有垃圾回收，不代表没有内存泄漏。最常见的泄漏源之一就是ThreadLocal。一个ThreadLocal实例被某个业务线程长期持有，而线程池里的线程并不销毁，那么ThreadLocal中存储的对象就一直被强引用——即使你不再用这个ThreadLocal了。如果ThreadLocalMap的key是弱引用，但value是强引用，那么key被回收后，value依然存在，直到线程关闭。每次用完ThreadLocal务必调用remove()，这是唯一安全的习惯。如果你担心“remove会删除其他方法的全局变量”，那说明你根本没有管理好ThreadLocal的生命周期。
第二个泄漏源是监听器。你在init里注册了一个事件监听器，却没有在destroy里注销。对于常驻进程（如Tomcat），类加载器会保留这个引用，导致整个应用无法被回收，甚至出现PermGen/Metaspace OutOfMemory。任何注册行为，都必须找到对应的注销行为，这不是“建议”，而是“必须”。第三个泄漏源是静态集合。你把数据库返回的数据放到public static List里当缓存用，只增不减。这个集合会一直膨胀，最终拖垮堆内存。静态集合不是缓存，必须设置上限和淘汰策略，否则就是内存炸弹。
还有一个细节容易被忽视：InputStream或Reader在异常路径上没有被关闭，导致文件句柄泄漏。这类泄漏不会立刻抛异常，而是让你在运行几天后突然报“打开文件过多”。关闭资源不仅要在正常路径上，还要在异常路径上，try-with-resources正是为此而生。如果你坚持用finally手动关，也别忘记在关闭前检查引用是否非空。
习惯的力量，大于任何框架
上面提到的每一个细节，都不是高深的算法，也不涉及分布式理论。它们只是代码中那些“看起来没毛病”的角落。但正是这些角落，日积月累，形成了代码库的“技术债利息”。你可能会觉得“重构时再改”，但重构往往发生在项目后期，而债务在每一天的部署中偿还。真正的专业精神，不是会用多少框架，而是在最普通的语句里，始终保持对边界、对并发、对生命周期的敬畏。
从今天起，试试这几个不起眼的习惯：写方法前先想清楚返回值是否可能为null；所有catch块至少要写一条带上下文的日志；日期和时区永远显式声明；重写equals时顺手把hashCode写完；用computeIfAbsent替代get-then-put；用完ThreadLocal立刻remove()。这些习惯不会让你立刻写出性能卓越的系统，但会让你的代码在半年后、两年后仍然能被人读下去，能在事故发生时不至于让你凌晨三点爬起来看监控。代码是给机器执行的，更是给人阅读的。你每次写下那一行时，都在做一次选择——选择让未来更轻松，还是更沉重。
