Math.abs() 因被 JIT 编译器识别为 Intrinsics，直接映射为 CPU 原生 abs 指令，而手动实现（如三元运算或位运算）无法进入编译器白名单，不触发同等优化，性能更差。
Math.abs() 被 JIT 编译器识别为 Intrinsics，不是普通函数调用
当你写 Math.abs(x)，JVM（HotSpot）或 JavaScript 引擎（V8）不会真的去查方法表、压栈、跳转执行——它在 JIT 编译阶段就把它替换成一条或多条底层机器指令，比如 x86 上的 cdq; xor eax, edx; sub eax, edx（带符号扩展+异或+减法），或 ARM 上的 abs w0, w0。这叫 Intrinsics（内建函数）：编译器“认得”这个函数语义，直接映射到 CPU 原生指令。
而你手写的 x >= 0 ? x : -x 或 if (x ，即使逻辑等价，JIT 仍需生成分支预测、条件跳转、可能的流水线停顿。现代 CPU 对分支敏感，尤其当 <code>x 符号随机时，分支预测失败代价远高于一条 abs 指令。
- JIT 不会对三元表达式自动“反推”为 abs 指令，它只做局部优化，不跨语义推理
- 位运算实现如
(x ^ (x >> 31)) - (x >> 31)看似无分支，但右移符号位依赖平台（Java 中>>是算术右移，JS 中>>是有符号右移但行为受类型系统干扰），且 JIT 通常不将其识别为 abs 等价物，仍按通用位操作处理 - Intrinsics 是 JVM/引擎白名单里的“特权函数”，
Math.min、Math.max、Integer.bitCount同理；你自己写的等效代码永远进不了这个名单
为什么手动实现无法享受相同优化层级
关键不在“你写得不够短”，而在“编译器是否信任你的语义”。Math.abs() 的 contract 是稳定、无副作用、纯计算、输入输出确定——JIT 可以安全地内联、向量化、甚至在循环中 hoist（提升）它的计算。而自定义函数哪怕只有一行，只要没被标注为 @HotSpotIntrinsicCandidate（Java）或没在 V8 的 intrinsic table 里注册（JS），就只能走通用函数调用路径。
- Java 中，
Math.abs(int)在 HotSpot 源码里对应vmIntrinsics::_abs_i，C2 编译器看到它直接 emit 平台专用 abs 指令 - JavaScript 中，V8 的 TurboFan 会把
Math.abs映射到Int32AbsIR 节点，后续 Lowering 阶段直接转成abs机器码 - 你写
myAbs(x)，哪怕函数体就是return x ，JIT 仍需保留 call 框架，除非函数足够小且被内联——但内联后仍是分支逻辑，不是 abs 指令
JIT 是否会在循环中重复调用 Math.abs()？
会，但不等于“每次都重新算”。如果 Math.abs() 出现在热点循环里（比如 while (Math.abs(x) > threshold)），JIT 编译器会检测到该调用是循环不变量（loop-invariant）——只要 x 在循环体内不被修改，它就会把 Math.abs(x) 提升到循环外，只算一次。这是基于数据流分析的优化，和是否 Intrinsics 无关，但 Intrinsics 让它更容易被识别为纯函数（无副作用），从而更可靠地触发 hoisting。
- 如果你写成
while (x threshold)，JIT 仍可能做类似优化，但分支结构增加了分析难度，尤其当循环体复杂或存在别名风险时，优化可能被保守禁用 - 实测中，
Math.abs()在循环内的性能优势比单次调用更明显，因为 JIT 更愿意对它做激进的循环优化（如 vectorization、unrolling） - 注意：若
x是对象字段（如obj.value），且obj可能被其他线程修改，JIT 可能放弃 hoisting，此时Math.abs()和手动实现都会每次调用——但前者仍更快，因指令级优势未丢失
真正影响性能差异的，是编译器信任链而非代码行数
很多人以为“少写一行就快”，其实慢的根源在于：你写的代码必须经过完整的语义解释 → AST 构建 → 字节码生成 → 解释执行 → 热点识别 → JIT 编译 → 通用优化流程；而 Math.abs() 在字节码层面就标记了 intrinsic hint，跳过中间多层推理，直通指令生成。这不是语法糖，是编译器与标准库之间的一份隐式契约。
这也是为什么位运算实现反而更慢：它绕过了分支，却失去了 intrinsic 身份，又引入了平台相关性（如 JS 中 >> 31 对负数的处理在不同引擎有差异），JIT 不敢轻易优化，最终生成的代码既难读又低效。
