Java开发时–架构与工程实践缺陷

1. 面向对象设计的常见误区
过度继承与脆弱基类：通过继承复用代码（如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()；反之不强制，但应尽量保证不同对象哈希值不同。
2. 异常处理的工程化缺陷
异常类型滥用：

用RuntimeException代替受检异常：跳过编译期检查，导致错误未被处理；
自定义异常粒度不当：一个异常类覆盖所有场景（如BusinessException），难以通过异常类型区分错误原因。
异常信息缺失：捕获异常后仅打印消息（e.getMessage()），未输出堆栈跟踪（e.printStackTrace()或日志框架记录e），导致无法定位错误位置。

异常链断裂：捕获异常后重新抛出新异常时，未携带原始异常，破坏异常链：

try {
// 操作
} catch (IOException e) {
throw new BusinessException(“操作失败”); // 丢失原始异常信息
}

正确做法：将原始异常作为 cause 传入：throw new BusinessException(“操作失败”, e);

3. 集合框架的性能与逻辑陷阱
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），会导致集合认为二者相等，破坏预期逻辑。

4. 工程实践中的隐性风险
日志输出不当：

高频场景下同步日志（如System.out.println）会导致线程阻塞；
日志中包含敏感信息（密码、Token），存在安全风险；
未分级日志（全用info级别），导致错误日志被淹没。
依赖管理混乱：

引入冗余依赖（如同时依赖log4j和logback），导致类冲突；
依赖版本过低，存在安全漏洞（如 Log4j2 的 Log4Shell 漏洞）；
未锁定依赖版本，导致构建环境不同时依赖版本不一致。
代码复用与可读性失衡：

过度封装：为复用几行代码创建复杂抽象，增加理解成本；
重复代码：相同逻辑在多处复制，修改时需同步更新，易引发不一致。