在Java中System类常见用法有哪些_Java系统级API解析

System.out.println() 是 PrintStream 的实例方法，非黑盒函数；需防 null 输出、乱码（应设 -Dfile.encoding=UTF-8）及 out 被替换未恢复；System.nanoTime() 专用于耗时测量，不可转真实时间；System.getProperty() 受安全策略和运行时环境限制；System.exit() 会跳过 finally 和清理逻辑，Web 环境禁用。

如何正确使用 System.out.println() 而不踩空指针或乱码坑

它不是“打印函数”，而是 System 类中静态字段 out（类型为 PrintStream）的实例方法调用。常见误用是把它当成黑盒，忽略其底层依赖。

• System.out 默认绑定到 JVM 启动时的 stdout 流，但可被 System.setOut() 替换 —— 单元测试中常用于捕获输出，但替换后必须记得恢复，否则后续日志丢失
• 中文乱码多因终端/IDE 编码与 JVM 默认字符集不一致：启动时加 -Dfile.encoding=UTF-8 比在代码里转码更可靠
• 不要对 null 值直接 println 后再做逻辑判断 —— 它会输出字符串 "null"，但不会抛异常，容易掩盖真实空指针问题

System.currentTimeMillis() 和 System.nanoTime() 到底该选哪个

二者精度、用途、是否受系统时间调整影响完全不同，混用会导致计时偏差甚至负值。

• System.currentTimeMillis() 返回自 1970-01-01 00:00:00 UTC 的毫秒数，受系统时钟修改（如 NTP 校准、手动调时）影响，适合记录业务时间戳、计算超时截止时间
• System.nanoTime() 返回纳秒级单调递增计数器，不受系统时间跳变影响，但**不能转为真实时间**，只适用于测量耗时：

  long start = System.nanoTime();
  // do something
  long elapsed = System.nanoTime() - start; // 正确

• 避免跨 JVM 进程比较 nanoTime() 值；不同机器上数值无意义；不要用它做定时调度（应使用 ScheduledExecutorService）

为什么 System.getProperty("os.name") 有时返回空或异常

这是最常被当作“安全常量”使用的属性访问，但实际有明确限制和陷阱。

• 仅对 JVM 启动时已加载的系统属性有效；运行时通过 -Dkey=value 添加的属性可读，但通过 System.setProperty() 动态设置的属性**不一定能被所有组件识别**（如某些安全策略下被禁用）
• 关键属性如 "java.home"、"user.dir" 通常稳定，但 "os.name" 在 Docker 容器中可能返回 "Linux"，而 "os.arch" 可能是 "amd64" 或 "aarch64"，需组合判断
• 未声明权限的 Applet 或 SecurityManager 启用环境下，getProperty() 可能抛 SecurityException；生产环境建议提前缓存必要属性，避免重复调用

用 System.exit() 关闭 JVM 的隐含风险

它会立即终止当前 JVM，跳过所有 finally 块、未完成的线程、shutdown hook 之外的清理逻辑 —— 很多资源泄漏和数据丢失源于此。

• Web 应用中绝对禁止在 Servlet 或 Controller 里调用 System.exit()，容器（如 Tomcat）可能无法回收线程池或连接池
• 唯一合理场景是命令行工具的主流程出口；若需优雅退出，应注册 shutdown hook：

  Runtime.getRuntime().addShutdownHook(new Thread(() -> {
      cleanupResources();
  }));

• 子进程继承父 JVM 的 exit

  

  行为，但 ProcessBuilder 启动的子进程不受影响；别指望用 exit(0) 来“确认成功”，日志或返回码才是标准方式

真正难处理的从来不是怎么写这四行代码，而是搞清哪一行不该写、在哪种上下文里写了就收不回。