Collections.swap用于交换列表中两位置元素，简化手动交换操作。它直接修改原列表，适用于排序、洗牌等场景，但需注意索引越界、不可修改列表异常、LinkedList性能差及线程不安全问题。替代方案包括临时变量法（直观但冗长）和set返回值法（简洁但难读），推荐Collections.swap以平衡可读性与简洁性。
Java里，
Collections.swap方法其实就是为了方便我们交换列表中任意两个指定位置的元素而存在的。它提供了一种简洁、直观的方式来完成这个操作，省去了我们自己手动编写临时变量来交换值的步骤，尤其是在需要原地调整序列顺序时，它是个非常趁手的工具。
解决方案
Collections.swap方法的使用非常直接，它的签名是
public static void swap(List list, int i, int j)。你需要传入要操作的
List对象，以及两个需要交换元素的索引
i和
j。
看个例子：
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
public class SwapExample {
public static void main(String[] args) {
List fruits = new ArrayList<>();
fruits.add("Apple");
fruits.add("Banana");
fruits.add("Cherry");
fruits.add("Date");
System.out.println("原始列表: " + fruits); // 输出: [Apple, Banana, Cherry, Date]
// 交换索引为0和2的元素 (即 "Apple" 和 "Cherry")
Collections.swap(fruits, 0, 2);
System.out.println("交换后列表: " + fruits); // 输出: [Cherry, Banana, Apple, Date]
// 交换索引为1和3的元素 (即 "Banana" 和 "Date")
Collections.swap(fruits, 1, 3);
System.out.println("再次交换后列表: " + fruits); // 输出: [Cherry, Date, Apple, Banana]
}
} 这个方法会直接修改传入的
List对象，所以它是一个原地操作。它内部处理了索引边界检查，但我们作为调用者，最好还是确保传入的索引是有效的。
Collections.swap方法在哪些场景下能派上用场？
在我看来，
Collections.swap方法虽然简单，但在不少场景下都能展现出它的实用性。最直观的，就是那些需要对列表元素进行“重新排列”或者“局部调整”的场合。
比如，在一些经典的排序算法实现中，比如冒泡排序（Bubble Sort）或者选择排序（Selection Sort），核心操作就是不断地交换元素位置。虽然现代Java开发中我们更多会用
Collections.sort或者Stream API，但如果你出于学习目的或者特定性能考量需要手写这些算法，
Collections.swap能让你的代码看起来更简洁、更易懂，而不是每次都写三行代码（临时变量、赋值、再赋值）。
另一个常见的应用场景是列表的随机化（Shuffling）。虽然
Collections.shuffle方法已经为我们提供了洗牌的功能，但如果你想实现一个自定义的洗牌算法，或者只是想随机交换两个元素来模拟某种游戏逻辑（比如棋盘游戏中的方块移动），
swap方法就非常合适。设想一下，你正在开发一个拼图游戏，玩家点击两个方块，需要它们互换位置，这时
Collections.swap简直是量身定做。
此外，在一些数据处理或UI交互的场景中，比如用户拖拽列表项来调整顺序，后端接收到新的顺序后，可能需要对原始数据列表进行相应的调整。或者，在某些算法中，需要将特定条件的元素移动到列表的某个位置，通过多次交换也可以达到目的。我个人在处理一些需要快速原型验证的列表操作时，也倾向于用它，因为它的意图非常明确。
使用Collections.swap时需要注意哪些潜在的陷阱或性能考量？
尽管
Collections.swap用起来很顺手，但在实际开发中，有几个点是需要我们留意的，不然可能会遇到一些意想不到的问题，或者性能上的坑。
首先，也是最常见的，就是索引越界问题。如果你传入的
i或
j超出了列表的有效索引范围（
0到
list.size() - 1），方法会抛出
IndexOutOfBoundsException。虽然这在IDE的静态分析下可能不难发现，但在运行时动态计算索引时，就需要格外小心了。这是个基础但关键的错误点。
其次，
Collections.swap只能用于可修改的列表（Modifiable List）。如果你尝试在一个由
Collections.unmodifiableList()创建的不可修改列表上调用
swap，或者是在
Arrays.asList()返回的固定大小列表（虽然内容可变，但结构不可变）上操作，你会得到一个
UnsupportedOperationException。这在处理API返回的只读列表时尤其需要注意，如果需要修改，通常要先复制一份。
再来谈谈性能。
Collections.swap的内部实现其实就是通过
list.set(index, element)来完成的。对于
ArrayList这种基于数组实现的列表，通过索引访问和修改元素是O(1)操作，所以
swap的效率非常高。但对于
LinkedList这种基于链表实现的列表，
list.set(index, element)需要从头或尾遍历到指定索引，这会是O(n)的操作。所以，如果你在一个非常大的
LinkedList上频繁调用
swap，性能可能会成为瓶颈。这一点，在选择列表实现时就应该考虑到，或者在性能敏感的场景下，可能需要重新评估算法。
最后，一个比较隐晦的点是线程安全。
Collections.swap本身并不是线程安全的。如果在多线程环境下，多个线程同时对同一个列表进行
swap操作，可能会导致数据不一致。在这种情况下，你需要自己外部进行同步控制，比如使用
synchronized关键字，或者使用
Collections.synchronizedList()包装过的列表。
除了Collections.swap，还有哪些替代方法可以实现列表元素交换？各自有什么优劣？
当然，
Collections.swap并非唯一的选择。在Java中，我们至少还有两种常见的方式可以实现列表元素的交换，它们各有各的特点。
最“原始”的方式，也是我们学习编程时最早接触的，就是手动使用一个临时变量进行交换。
Listitems = new ArrayList<>(List.of("A", "B", "C")); System.out.println("原始: " + items); // [A, B, C] int i = 0; int j = 2; // 手动交换 String temp = items.get(i); items.set(i, items.get(j)); items.set(j, temp); System.out.println("手动交换后: " + items); // [C, B, A]
这种方法的优点是非常直观，易于理解，并且你对整个交换过程有完全的控制。它不依赖任何
Collections工具类，适用于任何支持
get()和
set()操作的列表。缺点是代码会显得比较冗长，每次交换都需要三行代码，可读性上不如
Collections.swap简洁。尤其是在需要频繁交换的场景下，会增加代码量。
另一种稍微“巧妙”一点的方法是利用List.set()
方法的返回值。
list.set(index, element)方法会返回被替换掉的旧元素。我们可以利用这个特性，在一行代码中完成交换，但可读性可能会有所牺牲。
Listitems2 = new ArrayList<>(List.of("X", "Y", "Z")); System.out.println("原始2: " + items2); // [X, Y, Z] int i2 = 0; int j2 = 2; // 利用set方法返回值交换 items2.set(i2, items2.set(j2, items2.get(i2))); System.out.println("利用set交换后2: " + items2); // [Z, Y, X]
这种方法的优点是非常紧凑，一行代码就能搞定。它避免了显式声明临时变量，看起来很“酷”。然而，它的可读性是最大的短板。对于不熟悉这种写法的开发者来说，理解这行代码的逻辑可能需要一点时间，因为它有点像一个嵌套的赋值操作。在团队协作或者代码维护时，这可能成为一个障碍。
综合来看，我个人还是倾向于在大多数情况下使用
Collections.swap。它在简洁性、可读性和功能性之间找到了一个很好的平衡点，同时也能享受到
Collections工具类带来的便利。手动交换在特定场景下（比如，你不想引入
Collections类，或者想对交换过程有更细粒度的控制）可以考虑，而利用
set返回值的方法，我通常会避免，除非是在追求极致代码行数的竞赛中，因为清晰的代码往往比“聪明”的代码更有价值。
