在服务器上执行java -version，输出第三行包含“64-Bit”字样就是64位JDK，没有这三个字则是32位JDK，绝大多数Linux和Windows服务器上，这个方法都能直接给出答案，不用再翻安装目录。
怎么查看服务器jdk是32位还是64位：命令行三步走
第一步：直接看java -version的输出
登录服务器,敲下这条命令：
java -version
看第三行，也就是以Java HotSpot(TM)开头的那一行：
- 64位JDK会显示
Java HotSpot(TM) 64-Bit Server VM，中间有明显的64-Bit。 - 32位JDK只显示
Java HotSpot(TM) Server VM，没有64-Bit字样。
举例说明，64位JDK 8的完整输出长这样：
java version "1.8.0_301" Java(TM) SE Runtime Environment (build 1.8.0_301-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.301-b09, mixed mode)
如果第三行少了一截，变成Java HotSpot(TM) Server VM,那这台服务器跑的就是32位JDK。
这个判断方法适用于Oracle JDK、OpenJDK以及大多数主流发行版，需要注意，个别基于OpenJ9的JDK版本输出格式略有差异,但多数情况下还是会明确标注64位或32位。
第二步：用file命令检查java可执行文件
命令行输出看不清的时候，直接查java这个可执行文件本身的二进制格式,一步到位。
先找到java的实际路径：
which java
然后用file命令分析它：
file $(which java)
输出结果中重点关注ELF后面的描述：
- 看到
ELF 64-bit LSB executable,说明是64位可执行文件。 - 看到
ELF 32-bit LSB executable,说明是32位。
这个方法绕过了JDK版本信息的差异，直接看二进制文件格式,在Linux服务器上非常实用。
第三步：核对JAVA_HOME目录结构
很多服务器配置了JAVA_HOME环境变量，但环境变量指向的位置和实际生效的JDK不一定一致,建议进安装目录再核对一遍。
查看JAVA_HOME：
echo $JAVA_HOME
进入JDK安装目录，重点看jre/lib子目录下有哪些平台架构目录：
ls $JAVA_HOME/jre/lib
- 存在
amd64或x86_64目录,基本可以确认是64位JDK。 - 存在
i386或i686目录，且没有amd64目录,则是32位JDK。
除此之外，也可以直接看java可执行文件所在路径的命名，多数Linux发行版会把64位JDK安装在/usr/lib/jvm/java-8-openjdk-amd64这类带架构标识的目录里,目录名本身就是线索。
代码级确认：在Java程序内部查看位数
如果服务器上跑了多个Java应用，你想确认某一个应用进程实际使用的是多少位JDK，可以在应用日志里加上一行代码,或者直接在服务器上写个临时测试类：
public class CheckJdkBit {
public static void main(String[] args) {
System.out.println("os.arch: " + System.getProperty("os.arch"));
System.out.println("sun.arch.data.model: " + System.getProperty("sun.arch.data.model"));
}
}
sun.arch.data.model直接输出32或64,是最明确的指标。os.arch在64位JDK下通常返回amd64或x86_64，32位JDK返回x86。
这个方式适合用在排查具体应用场景，比如某个应用加载了本地动态库，怀疑JDK位数不匹配时,用代码输出确认比猜更靠谱。
32位jdk和64位jdk有什么区别，为什么必须确认位数
服务器jdk位数判断不只是查个版本号那么简单，它直接影响应用能否启动、能用到多大内存、以及能不能加载特定的本地库。
先看一张对比表：
| 对比维度 | 32位JDK | 64位JDK |
|---|---|---|
| 内存上限 | 理论4GB，实际Java堆多数情况下只有2GB左右 | 远高于32位，受服务器物理内存限制 |
| 本地库兼容 | 只能加载32位.so或.dll | 只能加载64位.so或.dll |
|
垃圾回收表现 | 堆接近上限时频繁触发Full GC | 大堆场景下GC调优空间更大 |
| 适用场景 | 老旧应用、嵌入式环境、低内存服务器 | 生产环境主流选择 |
内存上限差异最致命
32位进程的内存寻址空间上限是4GB，由于操作系统内核和虚拟地址空间会占用一部分，Java堆实际可用内存通常只有2GB左右，服务器上跑着内存密集型应用，比如数据分析、大型中间件，用32位JDK很容易出现OutOfMemoryError。
64位JDK几乎没有这个顾虑,堆内存分配到十几GB甚至更高都是常见操作。
JNI本地库必须位数匹配
如果应用里用到了JNI加载本地动态库，JDK位数和动态库位数必须完全一致，32位JDK配64位本地库，启动时报错Native library xxx already loaded in another classloader或者UnsatisfiedLinkError的现象时有发生。
行业共识认为，2015年以后新部署的服务器应用，除非有明确的第三方依赖限制,否则都应该优先选用64位JDK。
什么时候不得不保留32位
少数老旧的第三方中间件，只发布了32位版本的本地库，还有一些老旧的部署脚本写死了-d32参数，这类场景下只能继续使用32位JDK，但从长远来看，这类环境应该逐步列入升级计划，毕竟Oracle官方文档已明确，Java 8是最后一个支持32位Windows的版本,Linux平台的32位支持也在逐步弱化。
服务器jdk环境变量混乱时，如何快速定位实际生效的位数
服务器上装了多个JDK的情况太常见了，PATH里一个版本，JAVA_HOME指向又一个版本，应用启动脚本再指定一个版本，这时候光看java -version可能被误导。
先确认当前shell实际用到的java
which java
这个命令返回的路径就是当前shell执行java命令时真正调用的位置，再到这个路径去执行java -version和file,得出的是实际生效结果。
再确认应用的启动脚本用哪个JDK
很多应用服务在启动脚本里显式指定了JAVA_HOME，比如/opt/app/bin/start.sh
里写死了：
export JAVA_HOME=/usr/local/jdk1.8.0_301
这种情况下，不能用which java的结果来判断，需要直接检查脚本内容,然后执行：
/usr/local/jdk1.8.0_301/bin/java -version
一个高频坑：/usr/bin/java被符号链接覆盖
部分服务器的/usr/bin/java指向了/etc/alternatives/java，这个软链可能指向32位JDK，而系统里明明装了64位，遇到这种情况，用ls -l /usr/bin/java查看软链指向，再用update-alternatives --config java切换到正确的版本。
排查思路整理成操作顺序：
- 执行
which java确定实际路径 - 执行
java -version看64-Bit关键字 - 执行
file $(which java)确认二进制位数 - 检查应用启动脚本里的JAVA_HOME
- 用
ls -l检查软链是否被替换
常见问题解答
Q1：怎么看服务器jdk版本是多少位？除了java -version还有其他方法吗
java -version是最直接的方法，看第三行有没有64-Bit，稳妥起见，建议配合file $(which java)查看二进制格式，再检查$JAVA_HOME/jre/lib下是否存在amd64目录，三种方法对照验证,结果基本不会有偏差。
Q2：32位jdk和64位jdk有什么区别，服务器上装哪个更合适
主要区别在内存上限和本地库兼容性，32位JDK的Java堆多数情况下只能用2GB左右，64位JDK可以充分利用服务器物理内存，服务器上如果内存大于4GB，或者应用有较大内存需求，直接选64位，如果应用依赖的第三方本地库只有32位版本,再考虑保留32位环境。
Q3：java -version显示没有64-Bit字样，但服务器系统是64位的，能用吗
能用，但性能上比较吃亏，64位操作系统可以运行32位JDK，只是Java进程可用的内存会被限制在2GB左右，对于大多数生产环境应用来说，这个内存空间太局促了，建议先确认是否有第三方依赖强制要求32位环境，没有的话直接换成64位JDK,避免后续内存溢出问题。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/759222.html
