算术右移看重符号，逻辑右移只看位，两者在高位补的数是完全不同的算术右移补符号位，逻辑右移补0，这是区分它们的核心，也是虚拟机、编译器里处理两者最本质的差异。
很多人在学习位运算时，能把左移、与或非搞得明明白白，偏偏在右移这里栽了跟头，尤其在虚拟机、底层编译原理甚至日常刷题中，一旦遇到负数，这个差别就直接影响结果是正是负、是死循环还是正常输出，今天就把这两兄弟彻底讲透，顺便聊聊它们在实战中到底怎么选、怎么避坑。
算术右移和逻辑右移的定义差异，先看二进制补位行为
不管在什么体系下，右移的本质就是按照某个规则，把二进制数的每一位往右边挪，关键在于最高位缺失之后，用什么值来填充。
算术右移：高位补的是符号位
算术右移的出发点，是“让数字的符号保持不变”，如果是一个正数，最高位是0，右移后高位全部补0；如果是一个负数（以补码形式存储），最高位是1，右移后高位全部补1，这样做的结果是，负数右移之后仍然是负数，且数值上接近“除以2的向下取整”。
举个例子，-2在32位机器上的补码是 ..1110，算术右移1位后，最高位补1，变为 ..1111，结果就是 -1，也就是说，-2 >> 1 的结果是 -1。
逻辑右移：高位一律补0
逻辑右移完全不关心符号，它把整个二进制串当成一个纯粹的无符号数来处理，右移后缺出来的高位，永远用0填充，仍以-2为例，其补码右移1位后，最高位变成0，结果是一个巨大的正数，在32位下等于 2147483647。
同样的原始数据，选错右移方式，数值天差地别，在Java中，>>是算术右移，>>>是逻辑右移，在C/C++中，则是由变量类型决定，signed int默认算术右移，unsigned int则是逻辑右移，这些规则看似简单,到了虚拟机层面却容易让人晕头转向。
虚拟机里看右移：JVM字节码与寄存器模拟的真实行为
把问题放到“虚拟机”这个场景中，很多人讨论的是JVM或自定义指令集模拟器，在Java虚拟机中，ishr指令专门做算术右移，iushr指令对应逻辑右移，两者在字节码层面是明确分开的，但在C语言编写的模拟器里，如果你随意使用>>处理一个有符号整数,可能压根走不到逻辑右移那一步。
JVM指令集中的处理：源码与字节码的映射死角
JVM面对Java代码时，>>和>>>会被直接编译成不同的操作码，但假如你直接分析class文件，或者写一个简易的JVM解释器，则需要自己决定如何实现这两条指令，业内专家指出，大部分教学用虚拟机在实现逻辑右移时，会先把操作数无符号化，再执行物理右移，从而避免C/C++编译器自动插入算术右移逻辑，这是实现细节中最容易踩坑的地方，因为很多初学者直接用>>实现iushr，结果负数全部出错。
实际场景中的三种选择策略
- CPU模拟器或指令集模拟器：接收的是无符号指令，按无符号处理
- Java字节码解释器：必须严格区分
ishr与iushr两条指令 - 编译器优化层：需要根据类型信息决定最终生成的机器码是SAR还是SHR
如果是研究JVM源码，share/vm目录下的bytecodeInterpreter和templateTable两个文件可以帮你定位到不同平台的指令模板，它们分别调用了C2编译器后端和汇编层的移位指令，这个路径是业内公认的JVM右移实现关键代码,值得亲自看看。
编程语言中的右移运算符差异：一张表对比主流语言
C/C++中的行为取决于类型，不够直观
C语言标准里明确说，对有符号负数执行右移是“实现定义”的行为，但你只要在主流平台（x86、ARM、RISC-V）上测试，无一例外都是算术右移，行业共识认为，现代编译器默认统一采用算术右移以保证硬件指令的直接映射，因此你在-8 >> 1上得到的结果永远是-4，但若改用unsigned int，你就拿到逻辑右移，结果为无符号的2147483644。
这种割裂导致跨平台代码里，只要变量类型不对，行为就崩，对于底层开发者，建议写死整型类型，比如int32_t、uint32_t,避免隐式转换带来的意外。
Java强制区分两份运算符，规避平台差异
Java的诞生初衷之一就是跨平台，所以在语言层面直接定了规矩：>>永远是算术右移，>>>永远是逻辑右移，这样一来，不管JVM跑在什么CPU上，结果都是可预期的，但从另一个角度看，Java工程师必须自己记得“什么时候该用哪个”，否则就踩坑，比如编写字节缓冲区时，读取一个int的高位字节并整合，如果你用了>>而非>>>，负数的高位字节会补1,导致最终合并的结果完全错误。
Python、JavaScript与Go的处理方式
Python中只有>>，它永远按算术右移执行，并不提供逻辑右移的运算符，原因是Python的整数是任意精度的，逻辑右移没有无符号语义，JavaScript则相反，它的>>是算术右移，>>>是逻辑右移，跟Java保持一致，但要注意它会把数字转为32位整数后再运算，Go语言则根据类型区分，int使用算术右移，uint使用逻辑右移，规则与C类似,但类型系统更严格。
如果你平时在Python里想拿到逻辑右移效果，只能手动加一个掩码：(n >> 1) & 0xFFFFFFFF,这种方式模拟无符号32位整数行为。
选错右移会造成哪些实际后果：死循环、地址错乱与算法翻车
二分查找死循环：负数右移向下取整的反噬
常见二分写法mid = (low + high) >> 1在low + high不溢出时没问题，但一旦low和high是负数，算术右移是向下取整，而逻辑右移不具备这个语义，若你在Java里写(low + high) >>> 1，同时又没有处理好数值溢出后的负数情况，代码行为瞬间崩掉，以low=-2, high=0为例，算术右移的中间值为-1，逻辑右移为2147483647,二分区间根本无从收敛。
哈希散列与无符号压缩：高位补1导致散列值分布异常
在做布隆过滤器、哈希槽位计算时，很多开发者习惯用右移去掉低几位，如果一个负数的>>把高位补成1，最终取模的散列值会集中在某个区间，比如在Redis或自研分布式框架的槽位计算中，无符号右移才是最值得依赖的做法，这个问题在排查线上流量倾斜时很难一眼看出，因为代码表面逻辑完全成立,只有生成环境压测才能暴露分布不均。
虚拟机地址翻译：符号扩展导致内存越界
在实现一个简易虚拟机时，如果需要把16位立即数加载到32位寄存器，必须考虑符号扩展，如果你天真地用逻辑右移拼接指令，那么负数立即数就会变成超大正数，轻则跳转错误，重则访问非法地址直接崩溃，实现中，优先使用算术右移重建带符号值的指令立即数，再通过无符号掩码过滤地址,才能保证跳转目标正确。
实战验证手法：用GDB观察SAR和SHR指令的执行差异
纸上谈兵没有用，建议直接在自己的Linux/Windows虚拟机里跑一段C代码观察汇编输出，以x86_64平台为例，int a = -8; int b = a >> 1;编译后生成的汇编指令是SAR（shift arithmetic right），如果改成unsigned int c = 0x80000000; unsigned int d = c >> 1;，生成的则是SHR（shift logical right）。
可以通过以下步骤快速验证差异：
- 在任意目录新建
test.c，写入两个函数分别对int和unsigned int做右移 - 编译
gcc -O0 -S test.c生成test.s - 打开
test.s搜索shr关键词，观察指令后缀是shrl（逻辑右移）还是shrl（算术右移的对应指令是sarl） - 如果使用
objdump -d查看机器码，SHR的机器码通常为D1 E8，SAR为D1 F8
如果你调试的是Java字节码，使用javap -c命令查看ishr和iushr的调用是否匹配源代码,即可确认虚拟机是否按预期执行。
关于虚拟机算数右移的逻辑判断，Q&A快速回复
问：汇编语言中如何判断一条右移指令是算术还是逻辑？
看操作码助记符，x86中SAR是算术右移，SHR是逻辑右移；ARM中ASR对应算术右移，LSR对应逻辑右移；RISC-V中srai是算术右移立即数，srli是逻辑右移立即数，如果在调试器中看到shr，再看高位填充值，补符号位是算术右移,补0就是逻辑右移。
问：Java里负数做逻辑右移后结果为什么是一个巨大的正数？
因为Java中>>>把高位全部补0，整数不再解释为补码负数，而是作为无符号正整数看待，例如-1 >>> 1结果等于2147483647，这一点在面试和底层框架源码中反复出现，JJWT、Netty、HashMap的源码里都大量使用了>>>处理无符号化逻辑。
问：写虚拟机时，模拟指令集是否一定要同时实现两种右移？
取决于目标指令集，RISC-V指令集中两种右移都是独立指令，缺一不可，如果只实现一种，某些依赖符号扩展的指令会执行错乱，建议在解码阶段区分OP_IMM内部的SRAI与SRLI两个funct3值，分别调用不同处理函数；而加法、减法、乘法指令则根据操作码直接复用同一套运算逻辑。
写在最后：性能无差别，语义区分才见真章
两种右移在CPU层面都只需要一个时钟周期，性能完全相同，真正决定代码质量的，是你在写虚拟机底层逻辑时是否明确自己需要的“语义”，如果你需要保留符号，必须走算术右移；如果你在做位图、压缩、哈希或者地址偏移计算，务必用逻辑右移，把这些细节融入代码习惯中,比记住任何概念都管用。