Runtime类不能获取JVM版本、类路径等信息，仅提供availableProcessors()、freeMemory()、totalMemory()、maxMemory()和gc()五个运行时状态与控制方法。
Runtime类能获取哪些运行时信息
Runtime类本身不提供“获取信息”的查询接口，它是一个控制入口，主要用来与JVM运行时环境交互。你不能用它读取JVM版本、类路径或系统属性——那些得靠System.getProperty()或ManagementFactory。Runtime真正暴露的是当前JVM进程的资源状态和操作能力。
可用的运行时状态方法有哪些
通过Runtime.getRuntime()拿到实例后，能调用的方法其实很少，但每个都有明确用途：
-
availableProcessors()：返回OS可见的CPU逻辑核心数（不是线程数，也不反映超线程是否启用） -
freeMemory()：返回JVM认为“当前未被占用”的堆内存字节数（注意：不是操作系统视角的空闲内存，且不包含元空间、直接内存） -
totalMemory()：返回JVM当前向操作系统申请的堆内存总量（可能远小于maxMemory()） -
maxMemory()：返回JVM堆内存上限（即-Xmx值，若未设置则为平台默认值；对G1等垃圾收集器，这个值在运行中可能动态调整） -
gc()：发起一次GC请求（只是建议，JVM可忽略；不要用于性能优化或内存泄漏排查）
为什么freeMemory() + totalMemory() ≠ 实际已用堆内存
这是最常被误解的一点：freeMemory()返回的是“从JVM内存管理器角度看，尚未分配出去的堆空间”，但它不等于totalMemory() - 已分配对象大小。原因包括：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- GC后内存可能未立即归还给JVM（尤其CMS、G1有预留缓冲区）
- 对象分配使用TLAB（Thread Local Allocation Buffer），部分空间已被线程预占但尚未写入对象
-
freeMemory()不统计永久代/元空间、压缩类空间、直接内存（ByteBuffer.allocateDirect()） - 某些GC算法（如ZGC）采用染色指针，
freeMemory()计算方式与传统不同
替代方案：想查真实运行时信息该用什么
如果目标是监控或诊断，别只盯着Runtime：
立即学习“Java免费学习笔记（深入）”；
- 查JVM启动参数、内存池详情、GC次数：用
java.lang.management.MemoryMXBean和GarbageCollectorMXBean - 查类加载、线程、编译、运行时版本：用
ManagementFactory对应的各种MXBean - 查系统属性（如
java.version、java.class.path）：用System.getProperty("key") - 查原生内存使用（Native Memory Tracking）：需启动JVM时加
-XX:NativeMemoryTracking=summary，再用jcmd <pid> VM.native_memory</pid>
Runtime类的设计初衷是“轻量级进程控制”，不是信息仪表盘。依赖它做容量评估或告警，容易误判。
