vector和hashtable效率低下的根本原因是锁粒度过大，所有操作均需获取全局独占锁，导致读写完全串行、扩容全量阻塞、功能过时且缺乏现代并发优化。
Vector 和 Hashtable 效率低下的根本原因在于锁粒度过大——它们对整个对象加一把独占锁，所有读写操作都必须串行执行，哪怕只是并发读取，也完全无法并行。
全局独占锁导致严重阻塞
Vector 的 add()、get()、size()，Hashtable 的 put()、get() 等所有 public 方法，都被 synchronized 修饰，等价于 synchronized(this)。这意味着：
- 线程 A 调用
get()时，线程 B 即使只想读另一个位置，也得等待； - 线程 C 执行扩容（涉及数组拷贝、元素迁移），其他所有线程全部挂起；
- 读多写少的典型场景下，本可高度并发的读操作，被强制降为单线程执行。
扩容过程完全串行且开销巨大
Vector 和 Hashtable 扩容不是分段或懒加载式的：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 扩容由触发线程独自完成，需重新分配数组、逐个复制元素、重哈希（Hashtable）；
- Vector 默认扩容 100%（翻倍），Hashtable 扩容需 rehash 全量键值对；
- 在高并发下，多个线程可能几乎同时触发扩容，但只有一个能进，其余全在锁外排队，浪费大量 CPU 时间。
功能设计过时，缺乏现代优化
它们诞生于 Java 早期，并未考虑高并发常见模式：
- Hashtable 不允许
null键或值，与现代 API 设计习惯冲突； - 没有支持批量操作、迭代器弱一致性、分段锁、CAS 无锁等机制；
- JDK 文档已明确标记为 legacy，不推荐用于新代码。
对比现代替代方案更显劣势
ConcurrentHashMap 使用分段锁（JDK 7）或 CAS + synchronized 优化桶级锁（JDK 8+），允许多个线程同时读、不同桶间并发写；CopyOnWriteArrayList 在读多写少场景下让读完全无锁。而 Vector/Hashtable 连最基础的读写分离都做不到。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
