vector和hashtable的线程安全性源于方法级synchronized，锁对象为this，保证单实例操作串行化但粒度粗、性能低；其与collections.synchronizedxxx本质相同，均属悲观锁，静态变量需额外同步。
Java中Vector和Hashtable的线程安全性，完全依赖于方法级别的 synchronized 关键字。它们不是靠额外工具类包装出来的“伪安全”，而是从设计之初就内置了同步机制——每个公开操作都独占一把锁（即当前实例对象本身），从而保证多线程环境下基本读写不会出现数据错乱。
锁对象是this，不是全局类锁
Vector 和 Hashtable 的所有公共方法，例如 add()、get()、put()、size()，源码中均被声明为 public synchronized。这意味着每次调用时，线程必须先获取该容器实例自身的监视器锁（monitor lock），也就是 this。
这带来两个关键事实：
- 同一个 Vector 实例上的并发操作会被串行化，线程安全；
- 但不同 Vector 实例之间互不干扰，各自持有一把独立的锁；
- 若多个线程分别操作不同的 Hashtable 实例，它们之间也不存在同步约束。
粒度粗、性能低，不适合高并发场景
由于锁作用在整方法上，哪怕只是读一个元素（如 get(0)）或查大小（size()），也要等待前一个同步方法执行完毕。这种“大锁”策略导致：
- 吞吐量受限，尤其在读多写少场景下浪费严重；
- 无法支持复合操作的原子性，比如“检查是否存在再插入”需手动加锁；
- 迭代时容易触发
ConcurrentModificationException，因为遍历过程未被保护，而其他线程可能正在修改结构。
与 Collections.synchronizedXXX 的本质一致
Collections.synchronizedList(new ArrayList()) 或 Collections.synchronizedMap(new HashMap()) 并非新机制，其底层逻辑和 Vector/Hashtable 完全同源：都是对每个方法加 synchronized(this)。区别仅在于：
- Vector/Hashtable 是具体实现类，锁逻辑写死在源码里；
- synchronizedList/synchronizedMap 是装饰器模式，运行时动态包装，更灵活（可指定自定义 mutex 对象）；
- 二者都属于“悲观锁”范畴，归类为重量级、独占式、不可重入（实际可重入，因 synchronized 天然支持）的同步容器。
注意静态共享状态下的陷阱
如果在 Vector/Hashtable 外部维护了一个静态变量（如计数器），并期望通过 synchronized 方法间接保障该变量的线程安全，那是无效的。例如：
- Vector 自身的
add()是线程安全的，但如果你在 add 后再更新一个 static int counter，这个 counter 操作不在 synchronized 范围内； - 此时需单独为 counter 加锁，推荐使用
synchronized (MyClass.class)或 static synchronized 方法； - 否则会出现典型的竞态条件：读-改-写未受保护，结果丢失。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
