异或交换在Java中不可用：对引用类型不支持，同地址变量交换结果为0，仅适用于整数且存在溢出、可读性差等问题；应使用临时变量或封装swap方法。
异或交换在 Java 中根本不能用
直接说结论：^（异或）交换两个变量值，在 Java 中对基本类型看似能跑通，但对引用类型完全无效；更关键的是，它在绝大多数实际场景下会出错——尤其是当两个变量指向同一内存地址时，结果直接变零。
常见错误现象：a = a ^ b; b = a ^ b; a = a ^ b; 这三行代码如果 a 和 b 是同一个变量（比如数组元素 arr[0] 和 arr[0]），执行完 a 就变成 0。这不是理论风险，是真实发生过的线上 bug。
- 只适用于
int、long等整数类型，float/double不能用异或 - 不适用于对象引用（
String、自定义类等），因为^操作符不支持引用类型 - 可读性差，维护时没人一眼看懂这三行在干啥，还容易手误写错顺序
Java 里真要“不借助第三个变量”，只有包装类 + 解包这一条路
Java 没有指针、不支持引用传递，所谓“不使用第三个变量”本质上是个伪命题——JVM 总得有个临时位置存中间值。但如果你非要语法上不写 temp 变量，唯一可行的取巧方式是利用包装类的不可变性和自动拆箱：
int a = 5, b = 8; a = a + b - (b = a); // 先赋值 b=a，再算 a = 原a+原b-新b → 实际是 a=原b
这个技巧依赖赋值表达式的求值顺序（从左到右，b = a 先执行），但它极度危险：
立即学习“Java免费学习笔记（深入）”；
- 仅对
int等数值类型有效，溢出时结果错乱（比如Integer.MAX_VALUE + 1） - 一旦涉及浮点数或复杂表达式，行为不可预测
- Java 编译器不保证所有版本都按此顺序优化，不同 JDK 版本可能表现不一致
为什么非得不用第三个变量？你可能被误导了
这个问题常出现在算法面试或老式 C 语言教材里，但 Java 的语义和运行机制完全不同。真实开发中：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 局部变量压栈开销几乎为零，
int temp不占额外内存（JIT 会优化掉） - 现代 JVM 对
temp变量完全内联，性能和“无临时变量”写法无差异 - 用
temp写法：清晰、安全、兼容所有类型、IDE 能正确重构
真正该关心的不是“能不能少一个变量”，而是“会不会改错引用”或“有没有并发修改风险”。比如在多线程环境下交换 AtomicInteger 的值，正确做法是用 compareAndSet，而不是琢磨异或。
那到底该怎么交换？就用最直白的 temp
别绕弯子，直接写：
int a = 5, b = 8; int temp = a; a = b; b = temp;
如果是在方法里交换两个字段，或者想复用逻辑，就封装成工具方法：
public static void swap(int[] arr, int i, int j) {
int temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
}注意：这个方法只对数组有效，因为数组是引用类型，但内部元素是可变的；别试图用泛型写通用 swap——Java 泛型擦除后无法处理基本类型，而装箱类型交换又涉及对象地址，根本换不动原始值。
最易被忽略的一点：所谓“不使用第三个变量”的执念，往往掩盖了更关键的问题——比如你其实在操作集合，应该用 Collections.swap()；或者你在写排序，该关注比较逻辑而非单次交换。把力气花在刀刃上，比抠字眼重要得多。
