enumeration 是 jdk 1.0 遗留接口,仅用于 vector、hashtable 等老集合及 servlet api(如 getparameternames),无 remove()、不支持泛型和增强 for 循环,遍历时需先调 hasmoreelements(),现代代码应优先使用 iterator。

Enumeration 是 Java 1.0 就有的老古董
它比 Iterator 早整整 4 年,只在 Vector、Stack、Hashtable 这些 JDK 1.0 的集合类里原生支持。现在你写新代码几乎不会主动用它——除非在维护 2000 年代初的遗留系统,或者读到某段用 elements() 或 keys() 返回 Enumeration 的老代码。
常见错误现象:Enumeration 没有 remove() 方法,也没法在遍历时安全删除元素;调用 nextElement() 前必须先调用 hasMoreElements(),否则抛 NoSuchElementException;它不支持泛型,返回值永远是 Object。
- 如果你在 Spring Boot 项目里看到
Enumeration,八成是某处调用了request.getParameterNames()或ServletContext.getAttributeNames()—— 这些 Servlet API 接口至今没改,得接着用 -
Enumeration的方法名是hasMoreElements()和nextElement(),不是hasNext()/next(),拼错会编译失败 - 别试图把
Enumeration强转成Iterator:它们没有继承关系,也不共享接口
Iterator 是标准迭代协议,Enumeration 不是
Iterator 是 Collection 接口定义的契约,所有现代集合(ArrayList、HashMap、ConcurrentHashMap)都靠它暴露遍历能力;Enumeration 是孤立的、无上下文的类型,既不实现 Iterable,也不能被 for-each 消费。
使用场景差异很实际:你写 for (String s : list),背后调的是 list.iterator();但 for (String s : enum) 编译直接报错 —— Enumeration 不支持增强 for 循环。
立即学习“Java免费学习笔记(深入)”;
- 想把
Enumeration转成Iterator?JDK 自带的Collections.list(enumeration).iterator()会一次性把所有元素装进ArrayList,内存不友好;更轻量的做法是手写一个包装类,重写hasNext()和next()委托给hasMoreElements()/nextElement() -
Iterator.remove()是唯一安全的遍历中删除方式;Enumeration根本没这能力,硬删只能靠外部同步 + 手动重建集合 - 并发场景下,
Enumeration对Vector或Hashtable的遍历仍可能抛ConcurrentModificationException(虽然它们是线程安全的),因为Enumeration不做 fail-fast 检查 —— 这反而容易掩盖问题
Servlet 和老 API 里躲不开 Enumeration
哪怕你完全不用 Vector,只要写 Web 应用,就大概率撞上它:HttpServletRequest.getParameterNames()、getHeaderNames()、ServletContext.getAttributeNames() 全部返回 Enumeration<string></string>。这是 Servlet 规范定死的,JDK 也改不了。
性能影响不大,但写法要适应:不能用流式操作,不能用 lambda,连 StreamSupport.stream() 都得先转成 Iterator 再转 Spliterator。
- 最简转换写法:
Iterator<String> iter = Collections.list(request.getParameterNames()).iterator();
—— 注意:这里生成的是ArrayList的Iterator,不是原始Enumeration的实时视图 - 如果参数很多,又只关心是否存在某个 key,别全取出来,用 while 循环 +
hasMoreElements()逐个比对更省内存 - 别在循环里反复调
request.getParameterNames():每次调都可能新建一个Enumeration实例,且某些容器实现可能有开销
遗留系统升级时 Enumeration 的兼容陷阱
把老系统从 JDK 1.4 升到 8+,Enumeration 本身不会崩,但容易出隐性 bug:比如有人写了 while (enum.hasMoreElements()) { Object o = enum.nextElement(); ... },却没处理 o 为 null 的情况 —— 现代集合返回的 Iterator 允许 null 元素,但当年 Hashtable.keys() 返回的 Enumeration 在 key 为 null 时行为未定义(实际会抛 NullPointerException)。
- 检查所有
Enumeration使用点,确认是否依赖其“不支持 remove”或“非泛型”特性;迁移到Iterator后,类型擦除可能暴露原本被忽略的ClassCastException -
Vector.elements()返回的Enumeration是 fail-safe 的(内部用快照),而Vector.iterator()是 fail-fast 的 —— 升级后并发修改可能突然开始抛异常 - 单元测试里别 mock
Enumeration,直接 new 一个匿名子类太麻烦;用java.util.Collections.enumeration(list)更可靠
真正麻烦的从来不是语法转换,而是那些藏在 Enumeration 背后的假设:线程安全模型、空值容忍度、迭代顺序保证、甚至 JVM 版本导致的底层实现差异。改一行 elements() 到 stream() 很容易,但得想清楚这一行原来扛着什么。










