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 之外的清理逻辑 —— 很多资源泄漏和数据丢失源于此。
立即学习“Java免费学习笔记（深入）”；
- Web 应用中绝对禁止在 Servlet 或 Controller 里调用
System.exit()，容器（如 Tomcat）可能无法回收线程池或连接池 - 唯一合理场景是命令行工具的主流程出口；若需优雅退出，应注册 shutdown hook：
Runtime.getRuntime().addShutdownHook(new Thread(() -> { cleanupResources(); })); - 子进程继承父 JVM 的 exit 行为，但
ProcessBuilder启动的子进程不受影响；别指望用exit(0)来“确认成功”，日志或返回码才是标准方式
真正难处理的从来不是怎么写这四行代码，而是搞清哪一行不该写、在哪种上下文里写了就收不回。
