HashSet 的 clear() 方法通过直接调用底层 HashMap 的 clear() 实现高效清空，时间复杂度 O(n)，仅置空引用、跳过哈希计算与扩容判断，无需手动干预内部结构。
HashSet 的 clear() 方法本身就是快速清空底层 HashMap 节点的标准方式——它不“额外加速”，但已是 JVM 层最直接、最高效的实现。
clear() 直接调用 HashMap 的清空逻辑
HashSet 内部持有一个 transient HashMap<e object> map</e>，所有元素都作为 key 存入该 map，value 固定为 PRESENT。调用 set.clear() 实际就是执行：
-
map.clear()—— 这是 JDK 原生实现，无需手动遍历或逐个 remove - 底层会遍历哈希表的每个桶（bucket），将所有 Node 引用置为
null - 不重建哈希表结构，不调整容量，仅释放元素引用
为什么它已经足够快？
时间复杂度为 O(n)，n 是当前实际元素个数（不是容量）。关键在于：
- 跳过哈希计算、键比较、扩容判断等开销，只做引用置空
- 比循环调用
remove()快得多（后者每次都要 rehash + 查找 + 链表/红黑树操作） - 比新建 HashSet 对象更省内存（避免重复分配哈希表数组）
不需要也不建议手动干预底层节点
你无法、也不应直接访问或操作 HashMap 内部的 Node 数组（如 table 字段），原因包括：
立即学习“Java免费学习笔记（深入）”；
- 该字段被声明为
transient且无公开 getter，属于封装实现细节 - 不同 JDK 版本（如 JDK 8 vs JDK 21）内部结构可能变化（链表/红黑树/Node 类型）
- 强行反射修改易引发兼容性问题或破坏并发安全假设
真正影响“清空速度”的其实是初始容量和负载因子
如果频繁 clear + add，可考虑初始化时合理设置容量，避免后续扩容带来的间接开销：
- 例如预估最多存 1000 个元素，可用
new HashSet(1024)（2 的幂） - 这样 clear 后再 add，只要不超过容量，就不会触发 resize
- 但 clear 本身耗时仍只与当前元素数相关，和初始容量无关
