Java开发中容易忽视的常见错误及解决方法
刚经历了一次线上服务崩溃，排查半天才发现罪魁祸首竟是那个你写了几百遍的Integer比较——这不是段子，是无数Java开发者踩过的坑的缩影。那些在编译期不报错、运行期偶尔抽风、日志里只留下诡异堆栈的问题，往往就藏在最不起眼的语法角落。越是看似简单的语法，越容易在特定场景下引爆致命错误，而问题的根源多半源于你对Java语言特性的一知半解。
别急着背八股文，先停下来想想：你上一次因为==和equals的误用而熬夜加班是什么时候？是不是还在用float计算金额？是不是觉得try-catch里直接e.printStackTrace()就万事大吉？这些“常识性错误”的反复出现，恰恰说明很多人从未认真审视过它们背后的设计原理。下文将剖析十余个高频易错场景，每个都曾让线上服务付出过惨痛代价，而解决方案往往只需一行代码的改动。
包装类型比较：你以为的==，其实是地址判断
最经典的陷阱莫过于对Integer、Long等包装类型使用==进行比较。很多人知道Integer在-128到127之间有缓存池，但一旦数值超出这个范围，==比的就是内存地址而非数值。例如：
Integer a = 100, b = 100; System.out.println(a == b); // true，利用了缓存 Integer c = 200, d = 200; System.out.println(c == d); // false，超出缓存范围，创建新对象
这种不一致性会让代码在测试环境永远正确，而压测或生产环境一旦数值变大立刻翻车。更隐蔽的是，如果代码中混合使用new Integer()和Integer.valueOf()，或者从JSON反序列化后直接比较，缓存机制完全无效。唯一的正确姿势是永远用equals()比较包装类型，或者使用Objects.equals()同时避免空指针。对于Long、Short同理，别迷信缓存池可以覆盖所有场景。
异常处理中的“吃异常”与“过度捕获”
许多开发者习惯在catch块里写e.printStackTrace()或者干脆什么都不写。把异常吞掉而不做任何记录或恢复，等于给系统埋下定时炸弹。异常处理的第一原则是“要么处理，要么传递”。所谓处理，至少应当记录日志（用Logger而非printStackTrace，因为后者可能输出到标准错误流，在容器环境下未必能捕获到），然后根据业务决定是否重新抛出或返回降级结果。更糟糕的是捕获了Exception这种顶级异常，却指望能处理所有子类异常——你根本不知道NullPointerException和ArithmeticException该用同一套逻辑应对吗？
另一个常见错误是在finally块中return，吞掉了try块中的异常。例如：
try { return riskyMethod(); } finally { return 0; // 覆盖了原有返回值且吞掉异常 }
这种写法会让调用方永远得到0，而真正的问题被掩埋。异常处理中切勿在finally里使用return或throw，除非你明确要覆盖原有行为并记录日志。
字符串拼接的“隐藏成本”与线程安全
循环中使用+拼接字符串是新人最易犯的性能错误之一。String是不可变类，每次+都会创建新的StringBuilder对象（编译期优化后实际上会生成new StringBuilder().append()），但在循环体内多次拼接时，每次迭代都会新建StringBuilder。一个简单的做法是显式声明StringBuilder并在循环外复用，避免频繁创建对象和垃圾回收压力。但即便用了StringBuilder，也要注意线程安全：StringBuilder非线程安全，若在多线程环境下追加字符，必须改用StringBuffer或加锁。
还有一个更隐蔽的错误：对字符串判空时使用str.equals("")而忘记判空，一旦str为null直接空指针。推荐用"".equals(str)或StringUtils.isEmpty(str)。永远记住：调用方法前确保对象非空，或者在方法内防御性判空。
浮点数运算：你算的6.6，实际是6.5999999
float和double是二进制浮点数，无法精确表示0.1这样的小数，因此在涉及金额、折扣、利率等场景中直接使用浮点数进行加减乘除会导致精度丢失。比如：
double a = 0.1 + 0.2; System.out.println(a); // 输出0.30000000000000004
踩过这个坑的开发者，后来都用BigDecimal并配合String构造器（不要用new BigDecimal(0.1)，它仍然不精确）。但BigDecimal也有陷阱：除法时必须指定精度和舍入模式，否则divide方法在无法整除时会抛ArithmeticException。货币计算永远使用BigDecimal(String)，并明确设置小数点后几位和舍入模式。此外，尽量避免在循环中频繁创建BigDecimal对象（它也是不可变类），必要时考虑使用long以分为单位存储金额。
集合框架：subList()和asList()的“视图陷阱”
List.subList()返回的是原列表的视图，而非新列表。这意味着对子列表的结构性修改（如增删元素）会直接影响原列表，反之亦然。更危险的是：在子列表上添加元素后，千万不要再操作原列表，否则会抛出ConcurrentModificationException，因为子列表内部维护了原列表的修改计数器。很多人会在循环中对子列表进行遍历并删除元素，结果触发惊悚异常。解决方法是：如果需要独立子列表，请new ArrayList<>(list.subList())显式复制。
另一个经典陷阱是Arrays.asList()返回的ArrayList并非java.util.ArrayList，而是Arrays内部类，它固定了长度——对这个列表调用add或remove会抛UnsupportedOperationException。因为它的底层是原生数组，无法扩容。正确的做法是将其作为构造参数传入真正的ArrayList：new ArrayList<>(Arrays.asList(...))。任何情况下都不要试图修改Arrays.asList()返回的列表的结构，只用于读取或遍历。
equals()与hashCode()：不遵守契约的后果
如果重写了equals()但没有重写hashCode()，集合类（如HashMap、HashSet）就会表现出“判等却不判等”的诡异行为。例如，你定义了一个Person类，用id字段作为相等依据，但hashCode()没重写，那么两个id相同的Person对象会被放入不同桶中，导致HashMap.get()永远找不到匹配项。《Java核心技术》中说过：覆盖equals时必须覆盖hashCode，否则集合类无法正常工作。这个错误非常隐蔽，因为单测通常不会用集合来验证，只有集成测试时才发现某些对象“丢失”了。
正确的做法是：equals中参与比较的字段，在hashCode计算时也应包含；推荐使用Objects.hash(field1, field2)生成哈希值。另外注意，equals必须满足自反性、对称性、传递性和一致性，且与null比较应返回false。为每个需要比较的类编写严格的单元测试，测试集合功能的正确性。
线程安全：SimpleDateFormat与时间格式化
SimpleDateFormat不是线程安全的，它的内部使用了一个Calendar实例，多线程并发调用format()或parse()时会抛出NumberFormatException或产生错误的日期结果。在Web应用或其他高并发场景中，静态的SimpleDateFormat字段简直是灾难。很多项目里，开发者为了方便将SimpleDateFormat声明为static final，结果线上偶尔出现“无法解析的日期”错误，复现又困难。
解决方案有几种：一是使用ThreadLocal为每个线程保存一个实例；二是使用FastDateFormat（Apache Commons）或DateTimeFormatter（Java 8+）。Java 8引入的新时间日期API（java.time）是线程安全的，并且设计精良，应完全取代旧的Date和SimpleDateFormat。特别提醒，日期格式化一定要用DateTimeFormatter.ofPattern并指定时区，否则在不同时区的服务器上会解析出不同结果。
资源关闭：try-with-resources救了命，但仍有盲区
从Java 7开始，try-with-resources可以自动关闭实现了AutoCloseable的资源，但很多人在旧代码里仍然手动关闭流，并且经常忘记在finally块中关闭，或者关闭顺序不对导致资源泄露。即便使用try-with-resources，也有一个隐藏陷阱：多个资源声明时，关闭顺序是从后往前的，但如果你在finally块中仍然试图使用这些资源，可能已经关闭。更常见的错误是在资源关闭的catch块中又抛异常，导致原始异常被掩盖。try-with-resources会在关闭异常时抑制原始异常，但如果你自己又做了catch，可能丢失信息。
另外，对于一些非I/O资源（如java.sql.Connection的close方法可能回滚事务），直接使用try-with-resources可能会隐式回滚，导致业务逻辑出错。务必理解资源的语义：自动关闭只是释放物理连接，不代表回滚或提交。数据库连接池中的连接关闭其实是归还给连接池，而不是真正断开。
泛型类型擦除：你以为的List<String>，运行时只是List
Java的泛型是编译期实现的，运行时会擦除类型参数。很多人不理解这一点，于是在运行时通过instanceof检查泛型类型，或者试图创建泛型数组。例如：
List<String> list = new ArrayList<>(); if (list instanceof List<String>) // 编译错误：泛型信息不可用
因为泛型擦除，instanceof只能检查裸类型，不能检查具体参数化类型。正确做法是用Class对象作为参数传递来记录类型。另一个错误是创建泛型数组：T[] arr = new T[10];会编译失败，因为数组在运行时需要知道确切组件类型。解决方案是使用ArrayList<T>或通过Array.newInstance(clazz, size)反射创建。
还有，方法重载时，由于擦除会导致两个方法签名相同，例如void process(List<String> a)和void process(List<Integer> b)不能同时存在，因为擦除后都变成List。这些细节平时很少遇到，但一旦遇到，排查就会极其痛苦。
静态变量与类加载：你以为的全局变量，其实是多个ClassLoader的副本
在多模块或Web容器环境下（如Tomcat），每个模块可能有自己独立的ClassLoader。如果一个类被多个ClassLoader加载，它的静态变量就不再是全局唯一的。线上常见的“配置信息不更新”问题，往往是因为不同ClassLoader持有不同版本的静态变量。更危险的场景是：将static用作缓存，结果因为重复加载导致内存泄露——老版本类无法被GC回收，因为静态变量持有对象引用。
为此，对全局配置、单例对象，应确保只由同一个ClassLoader加载（如将类放在共享库中），或者使用依赖注入容器（Spring管理Bean）来避免静态变量混乱。在框架项目里，慎用静态变量存放可变状态，尽量交由IOC容器管理生命周期。
重写方法时的访问权限与返回值：能编译不代表正确
你以为@Override就是个装饰？它最大的作用是帮你检查是否真正重写了父类方法。很多人写子类方法时不小心把参数类型写错（比如Object写成了Object的包装类），导致方法变成重载而不是重写，而编译器和IDE不会主动提示（除非加上@Override）。建议为每个你认为的重写方法都加上@Override注解，让编译器帮你做类型检查。此外，重写方法的返回值类型可以是父类返回类型的子类型（协变返回类型），但访问权限不能降低（如父类protected，子类不能private）。这些Java基础规则在大型项目中极易被忽略，一旦出bug，定位起来非常耗费时间。
另一个极端是滥用@Override——如果你在一个接口方法上使用@Override，而该方法后来被从接口中删除，编译器会报错，这反而是好事，避免编译通过运行时调用失败。
日志框架的冲突与混乱：SLF4J绑定不唯一
一个大型项目中可能引入多个依赖，每个依赖可能自带不同的日志门面或实现（Log4j、Logback、java.util.logging）。SLF4J绑定了多个实现时，会在启动时输出警告并取其中一个，但运行时日志输出行为不可预测，可能某些日志被吞掉，也可能产生双重日志。更严重的是，如果某个旧依赖直接引用了commons-logging或log4j，而项目中又用了SLF4J+Logback，那么日志框架之间会用桥接包（如jcl-over-slf4j）来转换，但桥接配置错误会导致日志丢失。
解决方案：统一日志门面和实现，在Maven/Gradle中排除所有冗余的日志依赖，只保留一个实现（推荐Logback），并添加对应的桥接包。使用mvn dependency:tree检查依赖树，确保没有冲突。另外，日志配置中要避免将某些级别设置为OFF却不自知，导致排查问题时没有任何痕迹。
不可变的“假象”：对不可变对象集合的修改
你写了一个类，把所有字段设为private final，以为它就是不可变的。但如果某个字段是List或Map，并且你没有在构造器中做防御性拷贝，则可以返回原引用，调用方就能直接修改内部数据，破坏不可变性。真正的不可变类必须对可变字段进行深度拷贝，并在getter中返回不可修改的视图（如Collections.unmodifiableList()）。同理，对Date这样的可变对象，也需要在构造器里new Date(date.getTime())，否则外部引用可以修改内部时间。
这种缺陷会导致看似不该变化的值在运行时被意外篡改，特别是在多线程环境下引发数据不一致。不要信任调用方不会修改你返回的对象，防御性编程是Java开发者的必备技能。
代理与反射：你以为调用了目标方法，其实走了拦截器
Spring AOP、MyBatis Mapper等场景下，对象会被代理包装。如果直接对代理对象进行instanceof检查或者获取getClass()，会得到代理类而非原始类。很多人用obj.getClass().getAnnotation(SomeAnnotation.class)想获取类上的注解，结果返回null，因为真正的注解在原始类上，代理类没有。正确做法是用AopProxyUtils.getSingletonTarget()或者AnnotationUtils.findAnnotation()等工具类。
另外，在拦截器中对方法参数进行修改时，如果参数是基本类型或不可变对象，你的修改不会影响原始调用方法——你必须修改可变对象或将结果作为返回值。这些细节在框架源码中都有明确处理，但业务开发者往往忽略，导致逻辑错误却归因于框架Bug。
写了这么多，你可能会觉得“我都知道”，但请回想一下：上一次因为Integer比较而排查了半天的那个下午，你是不是忘了==的坑？知道和养成习惯是两回事，真正的正确做法是把这些常见错误嵌入代码评审清单中，并借助静态代码检查工具（如SpotBugs、SonarQube）自动扫描。此外，定期组织团队进行Code Review聚焦这些“低级错误”，比推荐任何书籍都有效。最后，永远保持怀疑：即使一行看起来完全正确的代码，也可能在特定条件下将你拽入深渊。当你习惯了在写每个==前都思考一下包装类型，在每个catch块里都写出有效的日志，在每次新建集合后都检查一下是否为视图——你才算真正掌握了Java的陷阱地图。