hashmap非线程安全但性能高，允许null键值；hashtable线程安全但性能差，不允许null键值；多线程场景推荐concurrenthashmap。
谈及Java集合框架中的
HashMap和
HashTable，很多初学者会觉得它们似乎差不多，毕竟都处理键值对。但深入一点，你会发现它们骨子里是两种不同的设计哲学，这直接决定了它们在不同场景下的表现和适用性。核心来说，
HashTable是线程安全的、不允许
null键值，且是遗留类；而
HashMap则非线程安全、允许
null键值，是更现代且性能通常更好的选择。
解决方案
理解
HashMap和
HashTable，最直接的切入点就是它们的线程安全性、对
null键值的处理、以及性能表现。
HashTable是一个同步的（synchronized）集合，这意味着它的所有公共方法都通过
synchronized关键字进行修饰，确保了在多线程环境下，同一时间只有一个线程可以访问
HashTable的任何方法。这自然保证了线程安全，但也带来了显著的性能开销，因为每次操作都需要获取和释放锁。此外，
HashTable不允许
null键和
null值。如果尝试插入
null，会抛出
NullPointerException。它的迭代器也不是“快速失败”（fail-fast）的。从继承体系上看，
HashTable继承自
Dictionary抽象类，这是Java早期集合框架的一部分，现在已经不推荐使用了。
HashMap则是一个非同步的（non-synchronized）集合，不保证线程安全。这意味着在多线程环境下，如果不进行外部同步处理，可能会出现数据不一致的问题。但作为交换，
HashMap在单线程环境下的性能通常比
HashTable要好得多，因为它避免了同步带来的额外开销。
HashMap允许且只允许一个
null键和任意数量的
null值。它的迭代器是“快速失败”的，这意味着在迭代过程中如果集合被修改（除了迭代器自身的
remove方法），会立即抛出
ConcurrentModificationException，这有助于快速发现并发修改问题。
HashMap实现了
Map接口，是Java集合框架中
Map家族的核心成员。
立即学习“Java免费学习笔记（深入）”；
简而言之，如果你需要一个线程安全的键值对存储，并且不介意性能上的牺牲，
HashTable可以工作，但更推荐使用
ConcurrentHashMap或
Collections.synchronizedMap。如果是在单线程环境，或者你能自行处理同步，那么
HashMap无疑是更优的选择，它提供了更好的性能和更灵活的
null值处理。
在多线程环境下，我该如何选择HashMap还是HashTable？
这确实是项目开发中一个很实际的问题。我个人在项目里，如果不是特别老旧的遗留代码，几乎不会主动去用
HashTable。为什么？因为它那个全局锁，简直是性能杀手。想象一下，即使是两个线程想访问
HashTable的不同部分，比如一个线程要
put一个键值对，另一个线程要
get另一个键值对，它们都得排队，因为整个
HashTable都被锁住了。这在并发量大的时候，性能瓶颈会非常明显。
所以，在多线程环境下，我的首选通常是
ConcurrentHashMap。它是一个专门为并发设计的
Map实现，通过“分段锁”（Java 7及以前）或者
CAS操作和
synchronized块（Java 8及以后）来提供比
HashTable细粒度得多的锁机制。这意味着不同的线程可以同时操作
Map的不同部分，大大提高了并发性能。它不仅线程安全，而且性能表现优秀。
如果你只是偶尔需要线程安全，或者你的应用场景对并发性能要求不是那么极致，也可以考虑使用
Collections.synchronizedMap(new HashMap<>())。这个方法会返回一个线程安全的
Map视图，它内部的所有操作都会被
synchronized包裹。虽然它提供了线程安全，但其同步机制和
HashTable类似，也是对整个
Map进行同步，因此在高并发场景下性能依然不如
ConcurrentHashMap。
总结一下：
-
高并发、高性能需求：
ConcurrentHashMap
是你的不二之选。 -
低并发、简单线程安全需求：
Collections.synchronizedMap(new HashMap<>())
是一个可行的方案。 -
遗留系统兼容或特殊场景：
HashTable
可能还会出现，但新代码不建议使用。
// 示例：使用ConcurrentHashMap
import java.util.concurrent.ConcurrentHashMap;
import java.util.Map;
public class ConcurrentMapExample {
public static void main(String[] args) {
Map<String, String> concurrentMap = new ConcurrentHashMap<>();
concurrentMap.put("key1", "value1");
concurrentMap.put("key2", "value2");
// 在多线程环境下安全地进行读写操作
new Thread(() -> {
concurrentMap.put("thread1_key", "thread1_value");
System.out.println("Thread 1 added: " + concurrentMap.get("thread1_key"));
}).start();
new Thread(() -> {
System.out.println("Thread 2 getting key1: " + concurrentMap.get("key1"));
}).start();
}
}HashMap允许null键值，这在使用中有什么潜在的陷阱或优势？
HashMap允许
null键和
null值，这确实为开发者提供了很大的灵活性，但也确实埋下了一些坑。
优势：
OSPod.CMS专业建站平台
下载
专业级别的大型网站建站产品，JAVA技术的CMS管理系统，ospod提供上百套专业模板供您选择，包括审批工作流，流量统计和流行网络应用，是公司企业建设专业网站的首选产品，也使用于专业建站人士完成复杂网站项目。管理地址cmsadmin登陆用户名:ospod 密码:ospod1234
-
表示缺失或未知：
null
值可以很好地表示一个键存在，但它没有关联任何具体的值，或者这个值是未知的。比如，你可以用map.put("username", null)来表示用户存在，但其昵称信息尚未设置。 -
简化逻辑： 在某些情况下，无需为“没有值”的情况设计特殊的占位符对象，直接使用
null
可以简化代码逻辑。例如，map.get(key)
返回null
，可以直接判断是键不存在，还是键存在但值为null
。
潜在的陷阱：
-
NullPointerException
风险： 这是最常见的陷阱。当你从HashMap
中获取一个值时，如果键不存在，get
方法会返回null
。如果键存在但其关联的值就是null
，get
方法也会返回null
。这两种情况都返回null
，这就很麻烦了。如果你不加区分地直接对这个返回的null
引用调用方法，就会触发NullPointerException
。Map<String, String> map = new HashMap<>(); map.put("name", null); // 键"name"存在，值为null // map.get("age") 会返回null，因为键"age"不存在 String name = map.get("name"); // System.out.println(name.length()); // 这里会抛出NullPointerException String age = map.get("age"); // System.out.println(age.length()); // 这里同样会抛出NullPointerException -
语义模糊：
map.get(key)
返回null
时，你很难一眼判断是“键不存在”还是“键存在但值为null
”。这需要额外的检查，比如使用containsKey(key)
来区分。if (map.containsKey("name")) { // 键"name"存在，值可能是null，也可能不是 String value = map.get("name"); if (value == null) { System.out.println("键'name'存在，但值为null"); } else { System.out.println("键'name'存在，值为: " + value); } } else { System.out.println("键'name'不存在"); } 一个
null
键的特殊性：HashMap
只允许一个null
键。如果你多次put(null, value)
，后面的值会覆盖前面的值。这通常不会造成问题，但如果预期有多个null
键对应不同的值，那就会出错了。
为了避免这些陷阱，我通常会建议在使用
HashMap时，尤其是在处理从外部或不可信来源获取的数据时，进行充分的
null检查。Java 8引入的
Optional类在一定程度上可以帮助我们更优雅地处理
null值，虽然它不能直接应用于
Map.get()的返回值，但可以在获取值后进行包装处理。
性能考量：为什么HashMap通常比HashTable快？
HashMap之所以通常比
HashTable快，核心原因在于它们的同步机制差异。这不仅仅是“一个同步一个不同步”那么简单，它背后涉及到并发控制的成本。
同步开销：
HashTable
的每个公共方法都被synchronized
关键字修饰。这意味着每次调用put()
、get()
、remove()
等方法时，线程都需要获取一个内部锁（通常是HashTable
实例本身）。获取锁和释放锁本身就是一种开销，即使在单线程环境下，这种机制也依然存在，只是没有竞争而已。一旦进入多线程环境，如果多个线程尝试同时访问HashTable
，它们就必须排队等待，只有当前持有锁的线程执行完毕并释放锁后，其他线程才能有机会获取锁并执行操作。这种粗粒度的同步（整个对象一把锁）严重限制了并发性能。无同步的自由：
HashMap
则完全没有内部同步机制。它假定使用者会自行处理并发问题，或者只在单线程环境中使用。因此，HashMap
在执行put()
、get()
等操作时，无需承担任何锁的获取和释放成本。在单线程环境下，这使得它能够以最快的速度执行操作。即使在多线程环境下，如果开发者能通过其他手段（比如外部锁、或者保证特定区域内无并发访问）来确保线程安全，HashMap
的这种“自由”也能带来更高的性能。迭代器：
HashMap
的迭代器是“快速失败”的，这意味着它在结构性修改（如添加或删除元素，而不是仅仅修改一个现有元素的值）发生时，会迅速抛出ConcurrentModificationException
。这虽然不是直接的性能提升，但它能帮助开发者及早发现并发修改带来的潜在问题，避免了更隐蔽的bug。HashTable
的迭代器不是快速失败的，在并发修改时可能会导致不确定的行为。底层实现细节： 虽然两者都基于哈希表原理，但
HashMap
在设计上更现代，比如它在Java 8中引入了红黑树（当链表长度超过阈值时），以优化哈希冲突严重时的性能，将最坏情况下的时间复杂度从O(n)降低到O(log n)。HashTable
则没有这样的优化。
所以，当你看到
HashMap和
HashTable的性能对比时，记住，
HashMap把线程安全的责任交给了开发者，从而换取了更高的执行效率。而
HashTable则把线程安全的责任揽到了自己身上，但代价是牺牲了性能。这是一个典型的“性能与安全”的权衡。
