LeetCode链表环检测：为何我的代码超时？

2024-07-08 07:37:08

LeetCode链表环检测：为何我的代码超时？变量赋值与性能的秘密

在LeetCode上挑战“链表环检测”问题时，你是否也曾遭遇代码超时的困扰？明明逻辑清晰，代码简洁，却依然无法满足时间限制的要求？本文将深入剖析这一问题背后的玄机，通过对比两种解决方案，为你揭示变量赋值对代码性能的影响，助你编写高效的解决方案。

问题背景：链表环检测

“链表环检测”问题要求判断一个链表中是否存在环。这一问题的经典解决方法是使用快慢指针：

慢指针：每次移动一个节点。
快指针：每次移动两个节点。

如果链表中存在环，快慢指针最终会在环内相遇。如果不存在环，快指针会率先到达链表尾部。

然而，在LeetCode提交代码时，时间限制是一道不可忽视的关卡。如果代码运行时间过长，就会超出时间限制，导致提交失败。

案例分析：变量赋值的微妙差异

让我们以两个代码示例为例，探究代码超时背后的秘密。示例A 在LeetCode上超时，而 示例B 则成功通过。令人惊讶的是，这两个示例的差异仅仅在于两行代码：

示例A（超时）

var hasCycle = function(head) {
  // ...
  let fastPointer = null;

  fastPointer = head?.next?.next || null;
  // ...
}

示例B（成功）

var hasCycle = function(head) {
  // ...
  let fastPointer = head;

  fastPointer = fastPointer?.next?.next || null;
  // ...
}

示例A 中，fastPointer 在循环开始时被赋值为 null，然后在每次循环迭代中更新。示例B 中，fastPointer 在循环开始时被赋值为 head，然后在每次循环迭代中更新。

看似微不足道的赋值差异，却导致了性能表现的天壤之别。

性能差异：代码细节决定成败

为何如此细微的代码差异会引发如此显著的性能差异？答案在于代码执行过程中的空值判断。

在 示例A 中，每次循环迭代都需要执行 head?.next?.next 的空值判断，即使 head 本身就为 null。这种不必要的空值判断增加了代码的执行时间，尤其是在处理长链表时，性能差异会被放大，最终导致超时。

相反，示例B 巧妙地避免了这种不必要的空值判断。如果 head 为 null，fastPointer 也会为 null，循环直接结束。只有当 head 不为 null 时，才会进行 fastPointer?.next?.next 的判断，从而节省了宝贵的执行时间。

因此，示例B 的代码更加简洁高效，执行速度更快，成功绕开了超时陷阱。