enummap底层使用数组而非哈希表，以枚举ordinal()为下标实现o(1)查表；无哈希计算、无冲突处理、无装箱，性能比hashmap高2–3倍、内存低约40%；不支持null键，且必须在编译期确定枚举类型。
EnumMap底层用的是数组不是哈希表
因为EnumMap只接受枚举类型作为键，JVM在类加载时就能确定该枚举的所有实例个数和顺序。所以EnumMap内部直接用一个Object[]数组存储值，下标就是枚举ordinal()值——查表操作，O(1)，无哈希计算、无冲突处理、无装箱。
- 每次
put(K key, V value)只是往table[key.ordinal()] = value写入 - 每次
get(Object key)先校验是否为同一枚举类，再取table[((Enum)key).ordinal()] - 不支持
null键（枚举实例本身不能为null），但值可以为null
HashMap对枚举键要额外付出三重开销
用HashMap<someenum v></someenum>看似方便，但实际每操作一次都在“浪费”：
- 枚举实例要自动装箱成对象（虽然轻量，但仍是对象分配）
- 每次
hashCode()调用本质是返回ordinal()，但得走虚方法分派 + 方法查找 - 还要做哈希扰动、桶索引计算、可能的链表/红黑树遍历——哪怕只有1个元素，这些逻辑全走一遍
实测在百万次put/get循环中，EnumMap通常比HashMap<enum v></enum>快2–3倍，内存占用低约40%（没Node对象、没负载因子扩容冗余）。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
EnumMap不支持运行时动态枚举类型
这是硬限制：构造EnumMap时必须传入枚举类字面量，比如new EnumMap(Color.class)。如果试图用反射获取的Class extends Enum>变量传入，编译期不报错，但运行时会抛IllegalArgumentException，提示“not an enum class”。
- 不能用泛型擦除后的
Class变量替代字面量 - 不能用于接口或抽象类约束的“伪枚举”（比如用
public static finalint模拟） - 序列化没问题，但反序列化要求目标类必须已加载且仍是同一枚举类
遍历顺序天然有序，但别依赖它做业务逻辑
EnumMap的keySet()、values()、entrySet()返回的集合，迭代顺序严格对应枚举定义顺序（即ordinal()升序）。这不是巧合，是数组下标遍历的自然结果。
- 适合做配置映射、状态码翻译等需要稳定顺序的场景
- 但若业务逻辑隐式依赖这个顺序（比如“第一个是默认值”），一旦枚举加了新常量到开头，就可能出错
- 比起
TreeMap的显式排序，EnumMap的有序性更轻量，但也更隐蔽——容易被当成理所当然
真正关键的不是它快，而是它的快建立在编译期可推导的前提上；一旦这个前提松动（比如换成非枚举类型、或者用代理/ASM动态生成枚举），整个优化基础就塌了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
