EnumMap 底层是基于枚举 ordinal() 的 Object[] 数组，O(1) 访问无哈希开销；不允许 null key，泛型强制 K extends Enum<K>；空间固定、遍历有序、性能优于 HashMap，适用于封闭枚举场景。
EnumMap 的底层是数组，不是哈希表
EnumMap 不走 hashCode() + 拉链/红黑树那一套，它内部用的是 Object[]，索引直接对应枚举常量的 ordinal() 值。比如 Color.RED.ordinal() == 0，那它的值就存在数组第 0 位——纯数组访问，O(1) 且无哈希计算开销。
常见错误现象：NullPointerException 出现在 put 一个 null 枚举实例时（EnumMap 不允许 key 为 null）；或者误以为能存非声明枚举类型的值，结果抛 ClassCastException。
- 必须用编译期已知的枚举类构造，运行时不能换；
new EnumMap<SomeEnum>(OtherEnum.class)会直接报错 - 构造时传入的 Class 对象必须是具体枚举类型，不能是其父类或接口
- 数组长度 = 枚举类中常量个数，所以空间占用固定、可预测，没有扩容逻辑
EnumMap 只接受一种枚举类型作为 key
它的泛型约束是 <K extends Enum<K>>，强制 key 必须是某个具体枚举类的实例，且所有 key 都得来自同一个枚举类。这带来两个实际影响：类型安全强，但灵活性差。
使用场景：配置开关、状态映射、协议码转义等 key 集合完全封闭且已知的场合。比如 HTTP 状态码映射到描述字符串，用 EnumMap<HttpStatus, String> 就比 HashMap<Integer, String> 更安全、更快。
立即学习“Java免费学习笔记（深入）”；
- 不能混用不同枚举类型，哪怕它们有相同 name 或 ordinal；
enum A { X };和enum B { X }是完全不兼容的 - 如果枚举类后期新增常量，EnumMap 实例不受影响，但新常量的默认值是 null（除非显式 put）
- 遍历顺序严格按枚举常量声明顺序，不是插入顺序，也不是哈希顺序
为什么 put/get 比 HashMap 快？少三步运算
HashMap 的 put(K,V) 至少要算 hash、找桶、处理冲突；EnumMap 的 put(K,V) 只做三件事：校验 key 非 null、取 key.ordinal()、数组赋值。没有 hash 计算，没有位运算取模，没有节点对象创建。
性能差异在小数据量下特别明显。实测 10 个键值对的读写，EnumMap 通常比 HashMap 快 2–3 倍；即使到几百个，优势仍在，只是差距收窄。
- 没有装箱开销：枚举实例本身就是对象引用，不像
HashMap<Integer, V>要频繁 Integer.valueOf() - JVM 对
ordinal()优化极好，基本等价于字段读取，比调用任意其他方法都轻 - 数组访问天然局部性好，CPU 缓存友好；HashMap 的桶数组+链表/树结构更容易造成缓存不命中
别在 EnumMap 里存大量 null 值
虽然 EnumMap 内部数组大小固定，但如果枚举类有 100 个常量，你只 put 了其中 5 个，剩下 95 个位置都是 null——内存没浪费，但语义上容易误导。更麻烦的是，containsKey(k) 返回 false 时，你无法区分“真没存过”还是“存过但 value 是 null”。
这是 EnumMap 和 HashMap 的关键语义差异：HashMap 允许 put(k, null) 并保留该记录；EnumMap 也允许，但 get(k) 返回 null 时，你必须额外调用 containsKey(k) 才能确认是否存在。
- 如果业务逻辑依赖 “null 值有意义”，EnumMap 不适合；改用 HashMap 或包装一层
-
size()返回的是非-null value 的数量，不是数组长度 - 序列化时只保存非-null 条目，反序列化后缺失的索引位置仍是 null
真正要注意的，是把 EnumMap 当成“带类型约束的紧凑数组映射”，而不是“更快的 HashMap 替代品”。一旦 key 不确定来自哪个枚举，或者需要动态扩展 key 集合，它就不再适用。
