EnumMap比HashMap快在跳过哈希计算、避免冲突、省键引用，以ordinal直接数组寻址；但受限于枚举类型、不支持null、非线程安全、序列化困难且类加载器敏感。
EnumMap比HashMap快多少？关键在内存布局和索引计算
EnumMap的性能优势不是“稍快一点”，而是跳过了哈希计算、避免了哈希冲突、省掉了键对象引用——它本质是用枚举ordinal()当数组下标直接寻址。只要枚举值不多（通常＜128），它的get/put就是O(1)且常数极小。
实操建议：
- 确认你的键确实是
enum类型，且不会动态生成（EnumMap不支持null键，也不接受非枚举类） - 枚举定义顺序决定内部数组索引，
values()返回顺序必须稳定——别靠IDE自动重排枚举常量 - 如果枚举有1000个值，EnumMap会分配长度1000的数组，但大部分空着；此时空间换时间是否划算，得看实际key覆盖密度
不能用EnumMap的典型错误场景
常见错误现象：ClassCastException: java.lang.String cannot be cast to YourEnum 或 NullPointerException 在put时抛出。
原因往往是误把字符串或包装类当键传进去，或者试图存null键。
立即学习“Java免费学习笔记（深入）”；
使用场景限制明确：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 键类型必须是编译期确定的某个
enum，不能是Enum>通配泛型 -
put(null, value)直接抛NullPointerException，连防御性检查都不给机会 - 不能作为JSON序列化目标（多数库默认不支持EnumMap，会转成空对象或报错）
- 多线程写入必须手动同步——它不像
ConcurrentHashMap，本身不保证线程安全
EnumMap与EnumSet配合使用的隐含收益
当你同时需要“按枚举分类存储数据”+“快速判断某枚举是否启用”，用EnumMap<yourenum v></yourenum>配EnumSet<yourenum></yourenum>比用两个HashMap高效得多。
原因在于两者共享同一套ordinal映射逻辑，且EnumSet底层也是位向量（bit vector），查存在性是单次位运算。
示例对比：
EnumMap<Status, Integer> countByStatus = new EnumMap<>(Status.class);
EnumSet<Status> activeStatuses = EnumSet.of(Status.RUNNING, Status.PAUSED);
// 检查并计数，无需遍历、无需装箱
if (activeStatuses.contains(status)) {
countByStatus.merge(status, 1, Integer::sum);
}
注意：EnumSet.noneOf(YourEnum.class)创建的是空集，但底层数组长度仍是枚举总数——这点和EnumMap一致，别误以为“空=轻量”。
替代方案选型：什么时候该忍痛换回HashMap？
EnumMap不是银弹。遇到这些情况，强行用它反而埋坑：
- 枚举类可能被第三方库扩展（比如SPI注入新枚举值），而你的EnumMap初始化早于那些类加载——会导致
ArrayIndexOutOfBoundsException在put时爆发 - 需要支持“键不存在时返回默认值”，
EnumMap.get(key)只返回null，你得额外判空+提供默认，不如Map.getOrDefault(key, def)直觉 - 要序列化到外部系统（如Kafka、DB），而下游不认Java枚举语义——这时用
String作键的HashMap更稳妥 - 枚举值极少变动，但字段语义经常变（比如Status从“RUNNING/PENDING”扩到“RUNNING/PENDING/TIMED_OUT/ABORTED_BY_USER”），每次加枚举都得重新编译所有依赖EnumMap的模块
最易被忽略的一点：EnumMap的构造函数必须传Class<e></e>，这个Class对象如果来自不同类加载器（比如OSGi、模块化JDK环境），会导致IllegalArgumentException——错误信息里根本看不出加载器问题，只说“not an enum”。
