List获取最后一个元素方法：size()-1 vs Deque getLast

本文深入探讨了在Java中安全高效获取集合末尾元素的多种方式，指出直接使用`list.get(list.size()-1)`虽常见却易因空指针、越界或低效实现（如LinkedList的O(n)遍历）引发问题；推荐优先进行`null`和非空校验，或转向语义更清晰、性能更稳定的`Deque.getLast()`（尤其搭配`ArrayDeque`），同时警示不可变集合、类型不兼容及过度依赖第三方工具的风险，并提醒开发者反思频繁访问末尾元素背后可能存在的设计隐患——真正关键的不是“怎么取”，而是“为何必须取”。

用 list.get(list.size() - 1) 获取最后一个元素，但要先判空

直接用 size() 减 1 取索引是最常见做法，但它在空 List 上会抛 IndexOutOfBoundsException。不是所有调用方都记得加判断，尤其当 List 来自外部 API 或可选配置时。

• 必须检查 list != null && !list.isEmpty()，只判空不判 null 也会 NPE
• ArrayList 的 get() 是 O(1)，但 LinkedList 是 O(n) —— 它得从头遍历到倒数第一，实际性能可能比你预期差很多
• 如果只是读取、不修改，这个方式足够轻量；但如果后续还要频繁访问首尾，就该考虑换数据结构了

改用 Deque 的 getLast() 更语义清晰，但要注意实现类差异

Deque 接口明确支持“末尾操作”，getLast() 比 get(size()-1) 更直白。但不是所有 Deque 实现都高效支持随机末尾访问。

• ArrayDeque 的 getLast() 是 O(1)，推荐作为默认选择
• LinkedList 虽然也实现了 Deque，但它的 getLast() 是 O(1)（内部维护了 tail 指针），这点比用 get(size()-1) 强得多
• PriorityQueue 不是 Deque 实现，不能用；别看到“队列”就以为能调 getLast()
• 如果原有代码用的是 List，强转成 Deque 会编译失败 —— 得重构上游类型或做适配

遇到 UnsupportedOperationException 时，大概率是不可变 List

像 Collections.unmodifiableList()、Arrays.asList() 返回的列表，或者 Guava 的 ImmutableList，它们的 get() 没问题，但如果你误用了 removeLast() 或试图往 Deque 里写，就会触发这个异常。

• Arrays.asList(...).get(0) 没问题，但 (Deque) Arrays.asList(...).getLast() 编译不过，运行时更不会成功
• 不可变集合通常没有 Deque 接口，强行转型会报 ClassCastException
• 如果不确定来源，优先走安全路径：判空 + get(size()-1)，而不是假设它支持 Deque

要不要为“取最后一个”专门引入新依赖？一般不用

Apache Commons Collections 有 CollectionUtils.get(collection, -1)，Guava 也有类似工具方法，但它们只是语法糖，底层还是判空+索引计算。

• 加一个依赖只为一行逻辑，增加维护成本，不值得
• 如果项目已用 Guava，Iterables.getLast(iterable) 可以处理 Iterable，比手写更稳；但对 List 还是不如原生 get() 直观
• 真正该警惕的是：为什么频繁需要最后一个元素？是不是数据建模时把“最新项”当成了隐式状态？这种隐含逻辑比取值本身更难调试

边界情况永远比想象中多——比如 size() 返回 long 的自定义 List 实现（极少见但存在），或者并发修改导致 size 和实际元素数不一致。别只盯着“怎么取”，先想清楚“为什么必须取最后一个”。

好了，本文到此结束，带大家了解了《List获取最后一个元素方法：size()-1 vs Deque getLast》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！