会。&&短路，&不短路；前者在左操作数为false时跳过右表达式，后者始终执行两边，尤其在含副作用的布尔表达式中影响安全性与语义。

Java里&和&&到底会不会跳过右边表达式？

会。只有&&短路，&不会——这是最常被误用的根源。比如obj != null && obj.getValue() > 0能安全执行，换成&就可能抛NullPointerException。

短路不是“优化”，而是语义差异：&&定义为“左边为false时，右边不求值”；&是位运算符重载为布尔逻辑时的副作用，它必须两边都算。

• 函数调用、方法访问、数组索引等有副作用的表达式，放&右边会强制执行
• &&在if/while条件中才是安全选择
• 布尔变量之间用&几乎没意义，除非你刻意要避免短路

什么时候非得用&而不是&&？

真不多。典型场景只有一种：需要两边都执行，且结果还要做按位判断。比如权限掩码校验：

int permissions = getUserPermissions();
if ((permissions & READ_PERMISSION) != 0 & (permissions & WRITE_PERMISSION) != 0) { ... }

这里第一个&是按位与（操作int），第二个&是布尔逻辑与——但注意，它依然不短路。如果写成&&，逻辑没错，可一旦你后面加了日志或调试语句在右边，就可能漏掉。

立即学习“Java免费学习笔记（深入）”；

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 混合整数位运算和布尔逻辑时，&无法被&&替代
• 单元测试里模拟“两边都执行”的行为，比如验证某个方法是否被调用两次
• 极少数并发场景下，靠右侧表达式的副作用触发状态更新（不推荐，但有人这么干）

&在布尔类型上性能比&&差吗？

不差，但没意义。JIT编译器对简单布尔表达式优化很激进，两者生成的字节码差异微乎其微。别为了“性能”选&，那是拿可读性和安全性换毫秒级不可测的收益。

真正影响性能的是副作用本身：如果&&跳过的那个表达式本来要查数据库、解密字符串或遍历大集合，那省下的时间远比运算符开销重要得多。

• 用&&不是为快，是为不出错
• 用&不是为慢，是为“必须执行右边”
• 看字节码ifne/ifeq跳转逻辑，就能确认短路是否发生

IDE警告Condition 'x & y' can be simplified要不要理？

要理，而且大概率该改。IntelliJ这类提示通常意味着你写了boolean a = true; boolean b = false; if (a & b) {...}——纯布尔变量之间用&，既无位运算含义，又放弃短路，属于语义混淆。

除非你明确注释了“此处禁用短路”，否则一律换成&&。静态分析工具不是挑刺，是在帮你拦截未来可能因重构引入的null问题。

• 警告出现在布尔字面量、布尔变量、返回boolean的方法调用上，基本就是误用
• 如果右边是boolean方法但带副作用（比如logAndReturnTrue()），那就该把副作用拆出来，别藏在条件里
• 别用Boolean.TRUE & Boolean.FALSE这种包装类表达式——先拆箱再算，还可能空指针

事情说清了就结束。真正难的不是记住规则，是每次写&前多问一句：我是不是在用错的工具掩盖一个本该拆出来的副作用？