当前位置：首页 > news >正文

Java开发时出现的问题---架构与工程实践缺陷

news 2025/8/8 6:30:41

除语言和并发层面，代码设计、工程规范的缺陷更易导致系统扩展性差、维护成本高，甚至引发线上故障。

过度继承与脆弱基类：通过继承复用代码（如class A extends B），会导致子类与父类强耦合。若父类修改方法逻辑，子类可能崩溃（“脆弱基类问题”）。
替代方案：用组合（class A { private B b; }）替代继承，通过接口定义行为，降低耦合。
单例模式的滥用与风险：
- 线程安全问题：懒汉式单例若未加同步，可能创建多个实例；
- 序列化问题：默认序列化会破坏单例（反序列化创建新对象），需重写readResolve()返回单例；
- 测试困难：单例全局唯一，难以在单元测试中模拟或替换。
  建议：非必要不使用单例，可用依赖注入（DI）管理对象生命周期。
equals () 与 hashCode () 的契约破坏：
- 仅重写equals()未重写hashCode()：导致HashMap中键无法正确查找（如前文案例）；
- hashCode()实现不当：若返回固定值（如return 1），会使HashMap退化为链表，查询性能从 O (1) 降至 O (n)。
  契约要求：若a.equals(b) == true，则a.hashCode() == b.hashCode()；反之不强制，但应尽量保证不同对象哈希值不同。

异常类型滥用：
- 用RuntimeException代替受检异常：跳过编译期检查，导致错误未被处理；
- 自定义异常粒度不当：一个异常类覆盖所有场景（如BusinessException），难以通过异常类型区分错误原因。
异常信息缺失：捕获异常后仅打印消息（e.getMessage()），未输出堆栈跟踪（e.printStackTrace()或日志框架记录e），导致无法定位错误位置。
异常链断裂：捕获异常后重新抛出新异常时，未携带原始异常，破坏异常链：
```
try {// 操作
} catch (IOException e) {throw new BusinessException("操作失败"); // 丢失原始异常信息
}
```
正确做法：将原始异常作为 cause 传入：throw new BusinessException("操作失败", e);

ArrayList 与 LinkedList 的选择错误：
- 频繁随机访问（get(i)）用LinkedList：其时间复杂度为 O (n)，远低于ArrayList的 O (1)；
- 频繁插入 / 删除（中间位置）用ArrayList：需移动元素，时间复杂度 O (n)，而LinkedList为 O (1)（找到位置后）。
HashSet 的去重逻辑依赖 equals ()：HashSet底层依赖HashMap，元素去重需同时满足hashCode()相等和equals()为 true。若元素未重写这两个方法，会导致重复元素无法去重。
TreeSet/TreeMap 的比较器陷阱：依赖Comparable或Comparator排序，若比较逻辑与equals()不一致（如compare(a,b)=0但a.equals(b)=false），会导致集合认为二者相等，破坏预期逻辑。

日志输出不当：
- 高频场景下同步日志（如System.out.println）会导致线程阻塞；
- 日志中包含敏感信息（密码、Token），存在安全风险；
- 未分级日志（全用info级别），导致错误日志被淹没。
依赖管理混乱：
- 引入冗余依赖（如同时依赖log4j和logback），导致类冲突；
- 依赖版本过低，存在安全漏洞（如 Log4j2 的 Log4Shell 漏洞）；
- 未锁定依赖版本，导致构建环境不同时依赖版本不一致。
代码复用与可读性失衡：
- 过度封装：为复用几行代码创建复杂抽象，增加理解成本；
- 重复代码：相同逻辑在多处复制，修改时需同步更新，易引发不一致。