盘点Java中最没用的知识⑤:这3个老古董你还在代码里“考古”?

一、Stack类：“继承Vector”的历史bug，为何成了性能拖油瓶？

你是不是在学Java集合时，老师说过“栈结构用Stack类”？是不是在老代码里见过

"new Stack<>().push()"？但你知道吗？Stack类从Java 1.0就存在，它直接继承自Vector——这意味着它的所有方法（如

"push()"、

"pop()"）都自带

"synchronized"锁！单线程环境下，这把“多余的锁”会让你多花30%以上的性能；多线程环境下，它又不如

"ConcurrentLinkedDeque"灵活。现在连Oracle文档都建议“用Deque替代Stack”，你还在为它的“历史身份”买单？

实操案例1：单线程任务中，Stack比ArrayDeque慢3倍

某日志分析工具需要频繁“压栈-弹栈”操作记录日志。开发同学直接用Stack实现，压测时发现单线程处理10万条日志耗时450ms；换成

"ArrayDeque"后，同样操作仅需120ms——原来Stack的

"push()"方法继承了Vector的同步逻辑，即使没有多线程竞争，也要额外做锁检查和释放！

二、StringBuffer：“线程安全”的字符串拼接，为何被StringBuilder“碾压”？

“多线程下拼接字符串，必须用StringBuffer！”这是很多新手学Java时被灌输的“铁律”。但你知道吗？StringBuffer的方法（如

"append()"）同样被

"synchronized"修饰，而90%的字符串拼接场景根本用不到线程安全！现在

"StringBuilder"不仅性能是其2-3倍（无锁开销），API还完全兼容——除非你明确在多线程中拼接（概率极低），否则StringBuffer就是“性能浪费”的代名词！

实操案例2：高并发接口中，StringBuffer成“性能瓶颈”

某秒杀系统的“商品信息拼接”接口，为了“防止多线程数据混乱”，用StringBuffer拼接商品名称、价格等信息。压测时发现，100并发下接口响应时间从100ms飙升至800ms——原来每个

"append()"都要抢同一把锁，大量线程阻塞。换成

"ThreadLocal<StringBuilder>"（每个线程独立实例）后，响应时间直接降到120ms，性能提升6倍！

三、AWT/Swing的事件分发线程（EDT）：“GUI开发”的隐形炸弹，为何让界面卡成PPT？

如果你用过Java开发桌面应用（如Swing写的ERP客户端），一定遇到过“点击按钮没反应，界面卡成假死”的情况。问题就出在AWT/Swing的事件分发线程（EDT）——它是Swing唯一的UI线程，负责处理用户输入、绘制组件，但如果在EDT里执行耗时操作（如文件读取、数据库查询），就会阻塞整个界面！很多老代码为了“图方便”直接在EDT里写业务逻辑，你以为是“简单实现”，其实是“界面杀手”！

实操案例3：EDT阻塞导致界面“假死”，用户误以为系统崩溃

某医院管理系统（Swing开发）的“患者病历查询”功能，直接在按钮的点击事件（EDT中）执行数据库查询（耗时500ms）。医生点击查询后，界面完全卡住，直到查询完成才能操作——患者家属以为系统崩溃，投诉率飙升。后来改用

"SwingWorker"将查询任务放到后台线程，查询完成后通过

"publish()"更新界面，界面流畅度直接恢复！

避坑指南：这些“老古董”，到底该不该留？

1. Stack类：直接“退役”：新代码中用

"Deque"接口（如

"ArrayDeque"）替代，单线程用

"ArrayDeque"（更快），多线程用

"ConcurrentLinkedDeque"（无锁）。老代码迁移时，用

"Deque stack = new ArrayDeque();"替换

"Stack stack = new Stack();"即可。

2. StringBuffer：按需“下岗”：除非明确在多线程中拼接字符串（如

"Runnable"共享同一个StringBuffer），否则一律用

"StringBuilder"。团队规范中禁止无理由使用StringBuffer，避免性能浪费。

3. EDT操作：“异步”是底线：所有耗时操作（IO、计算）必须放到后台线程（如

"SwingWorker"、

"CompletableFuture"），仅允许在EDT中更新UI（如调用

"setText()"、

"repaint()"）。记住：“界面卡不卡，关键看EDT是否被占满”！

总结：Java里的“没用知识”，往往是“历史设计缺陷”或“场景错位”的产物。Stack的冗余同步、StringBuffer的性能浪费、EDT的阻塞风险——它们不是“完全不能用”，而是在99%的场景下“用了不如不用”。技术人最该培养的，是“用对工具”的直觉：新需求优先选现代API（如Deque、StringBuilder、异步线程），老代码迁移时果断替换——毕竟，你的时间，要花在“让系统更快、更稳”的地方！