本文探讨了在现代Java运行时环境中，`jsvc`工具中显示的`-client` JVM选项为何不可用。通过分析Java 8及更高版本的JDK/JRE结构，我们发现这些版本已不再包含独立的“客户端”JVM，而是默认并仅提供经过优化的“服务器”JVM。教程将详细解释这一现象，并指导用户如何理解和处理`jsvc`的JVM选项。
理解Java虚拟机类型：客户端与服务器
在Java的早期版本中，HotSpot JVM提供了两种主要的运行时模式：客户端（Client）JVM和服务器（Server）JVM。这两种模式针对不同的应用场景进行了优化：
- 客户端JVM (Client VM)：设计目标是实现快速启动和较小的内存占用。它通常使用一个优化的即时编译器（JIT），适用于桌面应用、客户端工具等对启动速度和资源消耗敏感的场景。
- 服务器JVM (Server VM)：设计目标是实现最大吞吐量和长时间运行的稳定性。它使用一个更高级、更复杂的即时编译器，需要更长的预热时间，但一旦预热完成，能提供更高的峰值性能。适用于服务器端应用、大数据处理等需要长时间高负载运行的场景。
这两种JVM通常通过lib/client和lib/server目录下的库文件来区分和加载。
jsvc工具中的JVM选项困惑
jsvc（Java Service Wrapper）是一个用于将Java应用程序作为守护进程（daemon）或Windows服务运行的工具。它允许用户指定要使用的JVM类型。然而，在某些系统上，尽管jsvc -help输出显示了-client选项，但尝试使用该选项时却发现它不可用，并且在JAVA_HOME目录下也找不到对应的lib/client目录。
立即学习“Java免费学习笔记（深入）”；
例如，jsvc -help的输出可能包含以下片段：
/usr/bin/jsvc -help ...
...
-jvm <JVM name>
use a specific Java Virtual Machine. Available JVMs:
'server'
-client
use a client Java Virtual Machine.
-server
use a server Java Virtual Machine.
...这表明jsvc似乎支持客户端JVM。然而，在Arch Linux ARM aarch64、macOS或较新的Windows系统上，用户可能只会发现lib/server目录，而lib/client目录则缺失。这导致了对jsvc选项与实际JVM可用性之间差异的疑问。
现代Java版本的JVM结构变化
造成上述困惑的原因在于Java平台自身的演进。从Java 8开始，尤其是Java 9模块化之后，Java Runtime Environment (JRE) 和 Java Development Kit (JDK) 的结构发生了显著变化。
1. 默认JVM类型的统一： 现代Java版本（例如Java 8 Update 121及更高版本，以及Java 11等）已经将服务器JVM作为默认且通常是唯一的JVM选项。这意味着即使不显式指定，java命令也会启动服务器JVM。通过java -help命令可以验证这一点：
C:\> java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
c:\>java -help
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available
-server to select the "server" VM
The default VM is server.从上述输出可以看出，Java 8已经明确指出“The default VM is server.”。
2. lib/client目录的移除： 随着服务器JVM的性能不断优化，其启动速度和内存效率也得到了显著提升，使得客户端JVM的优势不再明显。因此，为了简化JRE/JDK的结构，Oracle及其他OpenJDK发行版在较新版本中逐步移除了独立的客户端JVM及其对应的lib/client目录。
以JDK 11为例，其lib目录结构如下：
c:\Program Files\java\jdk-11.0.1>tree lib Folder PATH listing for volume OS Volume serial number is 00000051 4C32:5A1F C:\PROGRAM FILES\JAVA\JDK-11.0.1\LIB ├───jfr ├───security └───server
可以看到，lib目录下只有jfr、security和server子目录，而lib/client目录已经不复存在。这证实了在现代Java环境中，客户端JVM确实不再可用。
结论与建议
- jsvc帮助信息的滞后性： jsvc的帮助信息可能基于较早的Java版本或其通用设计，因此即使在当前Java环境中客户端JVM已不存在，其帮助文本仍可能显示-client选项。这并非jsvc的错误，而是Java平台演进带来的不一致。
- 现代Java的默认行为： 在Java 8及更高版本中，服务器JVM是默认且通常是唯一可用的JVM。其性能优化已经使其适用于绝大多数应用场景，包括过去可能倾向于使用客户端JVM的场景。
-
如何处理jsvc的JVM选项：
- 在现代Java环境中，无需尝试使用jsvc的-client选项。
- 直接使用jsvc的默认行为，它会自动选择可用的服务器JVM。
- 如果需要显式指定，可以使用-server选项，但这通常是多余的，因为这是默认行为。
总之，当您在现代Java环境中使用jsvc并发现无法使用-client选项时，请理解这是Java平台发展的结果。服务器JVM的广泛优化使其成为当前Java运行时环境中的标准和唯一选择。
