System类是JVM与底层资源的桥接入口，非操作系统控制工具；安全调用System.exit()仅限主程序主动退出，应避免在库或Web中使用，优先用return或异常；System.in/out/err可替换但有全局和线程安全风险；currentTimeMillis()用于时间戳，nanoTime()专用于耗时测量。
System 类不是用来“控制”系统的，它只是 Java 运行时环境的一个薄封装入口，核心作用是桥接 JVM 与底层系统资源（如标准流、时间、退出机制），不提供操作系统级控制能力。
如何安全调用 System.exit()？
该方法会强制终止 JVM，不触发正常 shutdown hook 之外的清理逻辑（比如未 flush 的 PrintStream 缓冲区可能丢数据）。
- 仅在主程序明确需要终止时使用，例如命令行工具解析到
--help后主动退出 - 避免在库代码、Web 应用 Filter 或线程池任务中调用 —— 它会杀掉整个进程，不是当前线程
- 推荐优先用
return或抛出受检异常来传递控制权，把退出决策留给上层 - 若必须调用，传入非零状态码（如
System.exit(1)）表示异常退出，便于 shell 脚本判断
System.in / System.out / System.err 的本质和替换风险
它们是静态 final 字段，类型分别是 InputStream、PrintStream、PrintStream。虽然可通过 System.setIn()、setOut()、setErr() 替换，但有明显副作用：
- 全局生效：所有后续对
System.out.println()的调用都会走新流，影响日志框架、第三方库输出 - 线程不安全：多个线程并发调用
setOut()可能导致中间态错乱 - 测试场景下可用（如重定向到
ByteArrayOutputStream捕获输出），但生产环境禁止动态替换 - 注意
System.out默认是带缓冲的，直接写入后不flush()可能看不到输出（尤其重定向到文件时）
System.currentTimeMillis() 和 System.nanoTime() 怎么选？
两者都返回时间，但语义和用途完全不同：
立即学习“Java免费学习笔记（深入）”；
-
currentTimeMillis()返回自 1970-01-01 00:00:00 UTC 的毫秒数，适合计算日期、设置超时、生成时间戳 —— 但受系统时钟调整影响（NTP 同步可能导致倒退或跳变） -
nanoTime()返回的是单调递增的纳秒计数（基于 CPU tick），只适合测量耗时（如long start = System.nanoTime(); ...; long ns = System.nanoTime() - start;），不能转为可读时间 - 不要用
nanoTime()做定时调度（如 sleep 精度依赖Thread.sleep()），也不要拿它和currentTimeMillis()做加减换算 - 高并发计时场景下，
nanoTime()调用本身有微小开销（通常 Date 或Instant便宜得多
System.getProperty() 能读哪些关键系统属性？
这是获取 JVM 启动参数和运行时环境信息的主要方式，常用键包括：
-
java.version、java.vendor：JDK 版本与厂商 -
os.name（如Linux）、os.arch（如amd64）、os.version：操作系统标识，用于条件加载 native 库 -
user.dir：JVM 启动时的工作目录（不是 classpath 路径！） -
file.separator、path.separator：跨平台路径分隔符（/vs\） - 注意：
System.getenv()读的是操作系统环境变量，和getProperty()无任何关系；后者只能读-Dkey=value参数或 JVM 内置属性
真正容易被忽略的是：所有 System 方法都是同步访问底层 OS 资源的，频繁调用 currentTimeMillis() 或反复 getProperty() 在热点路径里会有可观开销；而 System.arraycopy() 虽然高效，但它只是本地方法封装，不校验数组边界 —— 越界直接抛 ArrayIndexOutOfBoundsException，没额外保护。
