链表-两两交换(Java的三种解法)

链表-两两交换(Java的三种解法)

道题是链表操作的一个经典问题,掌握了它,你对链表的指针操作和递归思维会有更深的理解。只要你跟着我的思路走一遍,自己动手写写代码,很快就能独立解决这类问题!咱们现在就来聊聊这道题吧


1. 看到这道题目时我想到了什么,以及如何运用现实案例讲解

你有没有想过,生活中很多事情都像是“交换顺序”或者“重新排列”。比如说,你在排队买东西,队伍里的人两两交换位置,前面的人变成后面,后面的人变成前面,这就是一种“两两交换”的操作。

再举个贴近算法的例子:想象你在整理一排书,原本是按顺序摆放的,但你想把相邻的两本书交换位置,比如第1本和第2本换,第3本和第4本换,这样整个书架的顺序就变了。这就像链表的两两交换,我们需要调整指针,让相邻节点的位置互换。

业务场景:这道题在实际业务中有很多应用,比如:

  • 数据排序:在某些场景下,需要对数据进行局部重排,比如用户列表中两两交换显示顺序,用于A/B测试。
  • 任务调度:在任务队列中,调整任务执行顺序,比如优先级相邻任务交换,提升调度效率。
  • 游戏设计:在游戏排行榜中,动态调整玩家位置,比如相邻玩家交换,用于视觉效果或平衡机制。

2. 解法分析:至少3种解法,最优解法和最快解法

解法1:递归(Recursion)——直观且代码简洁

思路:用递归的方式处理链表的两两交换。每次处理当前节点和下一个节点,交换它们的位置,然后递归处理剩余的链表。终止条件是当前节点为空或下一个节点为空。

  • 时间复杂度:O(n),n是链表节点数量,每个节点只处理一次。
  • 空间复杂度:O(n),由于递归调用栈,最坏情况下为链表长度。
解法2:迭代(Iteration with Dummy Node)——更符合工程实践

思路:用迭代的方式处理链表,引入一个哑节点(dummy node)作为辅助,方便处理头节点交换。每次处理一对节点,调整指针完成交换,然后移动到下一对节点。

  • 时间复杂度:O(n),每个节点只遍历一次。
  • 空间复杂度:O(1),只用常数级额外空间。
解法3:迭代(Iteration without Dummy Node)——直接操作头节点

思路:与解法2类似,但不引入哑节点,直接操作头节点。需要额外处理头节点交换的情况,代码逻辑稍复杂,但也能实现两两交换。

  • 时间复杂度:O(n),每个节点只遍历一次。
  • 空间复杂度:O(1),只用常数级额外空间。
最优解法和最快解法
  • 最优解法:如果追求代码可读性和工程实践,推荐迭代解法(带哑节点),因为它空间复杂度低,逻辑清晰,容易维护。如果是初学者或面试中追求简洁,递归解法也是不错的选择。
  • 最快解法:在实际运行中,**迭代解法(带哑节点)**通常是最快的,因为它避免了递归的调用栈开销,且指针操作效率高。

迭代解法(带哑节点)模板(Java)

publicListNodeswapPairs(ListNode head){ if(head ==null|| head.next ==null)return head;ListNode dummy =newListNode(0); dummy.next

Read more

VsCode远程Copilot无法使用Claude Agent问题

最近我突然发现vscode Copilot中Claude模型突然没了,我刚充的钱啊!没有Claude我还用啥Copilot 很多小伙伴知道要开代理,开完代理后确实Claude会出来,本地使用是没有任何问题的,但是如果使用远程ssh的话,会出现访问异常,连接不上的情况。这时候很多小伙伴就在网上寻找方法,在vscode setting中添加这么一段代码。可以看看这篇博客 "http.proxy": "http://127.0.0.1:1082", "remote.extensionKind": { "GitHub.copilot": [ "ui" ], "GitHub.copilot-chat": [ "ui" ], "pub.name": [ "ui&

By Ne0inhk

一文掌握 Git 分支:本地管理 + 远程协作 + 最佳实践

前言:为什么分支如此重要? 在现代软件开发中,分支(Branch) 是 Git 最强大的特性之一。想象一下: * 🚀 你可以在不影响主代码的情况下开发新功能 * 🐛 你可以独立修复紧急 Bug * 🧪 你可以安全地尝试实验性想法 * 👥 团队成员可以并行工作而不互相干扰 这一切都归功于 git branch 命令。本文将带你从零开始,全面掌握 Git 分支管理的核心技能。 一、分支的本质:理解 Git 分支模型 在深入命令之前,先理解分支的本质: ┌─────────────────────────────────────────────────┐ │ Git 分支 = 指向提交的轻量级指针 │ │ │ │ main ──→ ● ──→ ● ──→ ● (最新提交) │ │ ↘ │ │ feature ──→ ● ──→ ● (独立开发线) │ └─────────────────────────────────────────────────┘ 关键概念: * 分支只是一个指向特定提交的指针 * 创建分支几乎零成本(只创建指针,不复制文件)

By Ne0inhk
PandaWiki:更轻量的开源知识库,问答效果到底如何?(本地部署教程+效果实测)

PandaWiki:更轻量的开源知识库,问答效果到底如何?(本地部署教程+效果实测)

开源 RAG 项目我之前主要围绕 RAGFlow 写了不少落地案例。RAGFlow 定位是大而全的企业级 RAG 引擎,所以社区里也一直有人吐槽:资源吃得多、处理慢。但这事儿某种程度上就是端到端全包(解析、切分、向量化、检索、权限、工作流、评测)的代价,工程体量上去了,默认就不可能太轻。 如果你想找一款更轻量的开源方案,主要用来处理产品文档、技术文档、FAQ、博客等内容,那可以看看今天要介绍的 PandaWiki。一句话总结:PandaWiki 更像开源版的知识库产品,而不是一个给工程师从零拼装的 RAG 引擎。 这个项目实际我也是近期才注意到,GitHub 目前 8.6K Star,看趋势图下半年热度是一路走高。我花了几天集中测了下,确实有一些可圈可点的地方,这篇就抓大放小,来和各位说道说道。 这篇试图说清楚: PandaWiki 的手把手本地部署过程、

By Ne0inhk