详解Dictionary抽象类与Map接口_Java集合框架的历史演进说明

大静君_6998

发布时间：2026-02-23 18:39:09

625人浏览过

来源于php中文网

原创

Dictionary 是 Java 1.0 的过时抽象类，JDK 1.2 起被 @Deprecated，由泛型 Map 接口取代；其子类 Hashtable 和 Properties 也已被 HashMap、ConcurrentHashMap 等现代实现替代，开发中应统一使用 Map。

详解dictionary抽象类与map接口_java集合框架的历史演进说明

Dictionary 是 Java 1.0 的遗留抽象类，早已被 Map 接口取代

Java 中的 Dictionary 是个过时的抽象类，从 JDK 1.0 就存在，但它在 JDK 1.2（1998 年）引入集合框架时就被明确标记为 @Deprecated，官方建议彻底停用。它只留下 Hashtable 和 Properties 两个子类，而这两个类本身也早被更现代的替代方案覆盖。

你几乎不会在新项目里主动写 new Dictionary()——因为它不能实例化；也不会去继承它——因为所有标准实现都已转向 Map 接口。它的方法签名也暴露了设计陈旧：比如 get(Object key) 返回 Object，没有泛型，不支持 null key/value（Hashtable 子类直接抛 NullPointerException），也没有集合视图（如 keySet()、entrySet()）。

Map 接口是实际开发中唯一该用的键值对契约

Map 是一个泛型接口，定义了现代键值映射的标准行为，所有主流实现（HashMap、TreeMap、LinkedHashMap、ConcurrentHashMap）都直接实现它，而非继承 Dictionary。它的设计更严谨、扩展性更强：

Map 明确区分了 key 不可重复、value 可重复的语义
提供三种集合视图：keySet()、values()、entrySet()，便于遍历和转换
支持泛型，编译期就能约束 K 和 V 类型，避免运行时 ClassCastException
允许 null key（HashMap）或禁止（ConcurrentHashMap），行为由具体实现决定，而非父类一刀切

示例对比：

立即学习“Java免费学习笔记（深入）”；

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

Map<String, Integer> map = new HashMap<>(); // ✅ 推荐，类型安全，API 丰富
map.put("a", 1);
Integer v = map.get("a"); // 编译期知道返回 Integer

// ❌ 不要再写（即使能编译）
// Dictionary dict = new Hashtable(); // 警告：Dictionary 已废弃
// Object o = dict.get("a"); // 返回 Object，需强制转型，且无泛型保障

为什么还有人看到 Dictionary？基本只出现在三类地方

现实中遇到 Dictionary，大概率不是你主动选的，而是被动踩坑：

老系统维护：JDK 1.1–1.4 时代写的代码，尤其是早期 Servlet 容器或 RMI 相关逻辑中残留的 Properties（它继承自 Hashtable，而 Hashtable 继承自 Dictionary）
反编译/IDE 提示干扰：某些老旧 jar 包字节码未更新，IDE 在跳转时显示 Dictionary 父类声明，但实际调用仍是 Map 方法
误读文档或面试题：部分中文资料把 “dictionary” 当作通用概念（如 Python 的 dict），混同于 Java 的 Map，造成术语混淆

注意：Properties 虽然继承链含 Dictionary，但它自己重写了关键方法（如 load()、store()），日常用它读配置文件完全没问题——但别把它当 Dictionary 来扩展，应视作专用于字符串键值的 Map<String, String> 特化工具。

迁移到 Map 时最容易忽略的兼容性细节

把老代码里的 Hashtable 换成 HashMap 看似简单，但有几个点不留意就会出错：

Hashtable 是线程安全的（方法全加 synchronized），HashMap 不是——如果原逻辑依赖其内置同步，直接替换会引发并发问题；应改用 ConcurrentHashMap 或外层加锁
Hashtable 不允许 null key 或 value，HashMap 允许一个 null key 和任意数量 null value；若旧代码隐式依赖非空校验，替换后可能触发 NullPointerException
Properties 的 getProperty(String key) 返回 String，而 Map.get(Object key) 返回泛型 V；若原逻辑靠 getProperty 做空判断（它返回 null 表示不存在），换成 get() 后需确认是否真没这个 key，还是值就是 null