Runtime类是JVM单例门面，仅支持exec()执行命令、gc()建议回收、addShutdownHook()注册关闭钩子等有限操作，无法配置JVM参数，现代开发应优先使用ProcessBuilder、ManagementFactory等替代API。
Runtime 类不能用来配置或改变 JVM 运行时环境，它只是当前 JVM 实例的单例门面，用于执行有限的系统级操作。
获取当前 JVM 的 Runtime 实例
只能通过 Runtime.getRuntime() 获取，不能 new、不能反射构造。这是典型的单例模式，且 JVM 保证全局唯一。
- 多次调用
Runtime.getRuntime()返回的是同一个对象引用 - 在模块化（Java 9+）环境下，每个模块加载器仍共享同一个
Runtime实例 - 试图通过反射调用私有构造器会抛出
IllegalAccessException
执行外部命令：用 exec() 而不是 System.exec()
Java 没有 System.exec()；实际是 Runtime.getRuntime().exec(...)。它不等价于 shell 执行，不解析重定向、管道或通配符。
-
exec("ls -l | grep java")会失败——|不被识别，需改用new ProcessBuilder("sh", "-c", "ls -l | grep java") - 推荐优先使用
ProcessBuilder，它对参数分隔更安全，避免 shell 注入和空格截断问题 -
exec(String)内部用空格分割命令，遇到含空格路径（如"C:\Program Files\java\bin\java.exe"）会出错；应改用exec(String[])
内存与 GC 控制：别信“强制回收”
Runtime.getRuntime().gc() 只是建议 JVM 执行垃圾回收，不保证立即执行，也不保证回收多少内存。
立即学习“Java免费学习笔记（深入）”；
-
freeMemory()、totalMemory()、maxMemory()返回的是 JVM 堆内存视图，不含 Metaspace、直接内存（Direct Buffer）、线程栈等 -
gc()在 G1 或 ZGC 等现代收集器上基本无实际效果；JVM 自己调度更高效 - 监控内存应依赖
java.lang.management.MemoryUsage和 JMX，而非靠Runtime轮询
添加 JVM 关闭钩子：addShutdownHook() 的真实行为
注册的 Thread 会在 JVM 正常退出（如 System.exit(0)、收到 SIGTERM）前运行，但不响应 SIGKILL（kill -9）或崩溃场景。
- 钩子线程必须是
NON-DAEMON，否则可能被忽略 - 多个钩子按注册顺序反向执行（LIFO），但无明确同步机制，不要在钩子中依赖其他钩子已完成
- 钩子中禁止调用
System.exit()或再次注册钩子，会抛出IllegalStateException - 常见误用：在钩子里做耗时 I/O（如写日志到磁盘）——JVM 可能因超时直接终止该线程
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
System.out.println("正在清理临时文件...");
try {
Files.deleteIfExists(Paths.get("/tmp/app.lock"));
} catch (IOException ignored) {}
}));
真正需要干预 JVM 行为（如堆大小、GC 算法、类加载策略）得靠启动参数（-Xmx、-XX:+UseZGC），而不是 Runtime 类。它只暴露了极小一部分运行时能力，且多数已被更现代的 API（如 ProcessBuilder、ManagementFactory）替代或封装。
