安全调用 System.exit() 应限于命令行工具，Web服务须用 ApplicationContext.close()；System.getenv() 优先于 getProperty() 读敏感配置；性能计时禁用 currentTimeMillis()，改用 nanoTime()；arraycopy() 比循环快且需注意参数顺序；System 方法不可 mock，需抽象封装。
如何安全调用 System.exit() 避免服务意外终止
直接调用 System.exit(int) 会强制终止 JVM，线上服务中极易引发事故。它不走 Spring 的优雅关闭流程，也不会触发 @PreDestroy 或 ShutdownHook 的完整执行序列。
常见错误现象：Spring Boot 应用在执行定时任务时调用了 System.exit(0)，导致整个应用进程消失，注册中心心跳断连，流量被误切。
- 仅在命令行工具、单次脚本类程序中使用；Web/微服务场景下应改用
ApplicationContext.close()或依赖容器生命周期管理 - 若必须保留退出逻辑，先注册钩子：
Runtime.getRuntime().addShutdownHook(new Thread(() -> { /* 清理资源 */ }))，再调用exit() - 测试阶段建议用
SecurityManager拦截（JDK 17+ 已移除，但 JDK 8–16 可临时启用）防止误调
System.getProperty() 和 System.getenv() 怎么选
两者都用于读取运行时配置，但来源、权限和行为差异很大：
-
System.getProperty("user.home")读的是 JVM 启动参数（如-Duser.home=/tmp）或内置系统属性，受SecurityManager约束，部分属性（如java.class.path）在安全管理器启用时会抛SecurityException -
System.getenv("PATH")直接读操作系统环境变量，不受 JVM 参数影响，但无法通过-D覆盖；JDK 9+ 默认禁止修改环境变量（System.setenv()已失效） - 敏感配置（如数据库密码）不应放
system properties，因可能被 JMX 或 actuator endpoint 暴露；优先用getenv()+ 外部配置中心兜底
为什么 System.currentTimeMillis() 不适合做性能计时
它返回自 1970-01-01 UTC 的毫秒数，本质是系统时钟值，受 NTP 校准、手动调时、闰秒影响，可能出现回拨或跳变。
立即学习“Java免费学习笔记（深入）”；
典型问题：分布式链路追踪中用它计算耗时，某台机器被 NTP 同步回拨 5 秒，导致记录出负值或超长延迟假象。
- 替代方案统一用
System.nanoTime()：基于高精度单调时钟，不受系统时间调整影响，单位是纳秒，适合测量间隔 - 注意：
nanoTime()不代表真实时间点，不能跨 JVM 或持久化存储；如需关联日志时间戳，应同时记录currentTimeMillis()作参考 - Logback / Log4j2 默认使用的
Timestamp是currentTimeMillis()，高并发下无问题；但自定义的「请求耗时」字段必须用nanoTime()
System.arraycopy() 的实际性能优势在哪
这是 JVM 层面深度优化的本地方法，比手写 for 循环或 Arrays.copyOf() 更快，尤其在大数组、对象引用复制场景下。
使用场景：Netty 的 ByteBuf 扩容、FastJSON 反序列化时的字符数组拷贝、批量消息体组装。
- 参数顺序易错：
arraycopy(src, srcPos, dest, destPos, length)—— 第二个是源起始位置，第四个是目标起始位置，反了会导致越界或数据错位 - 目标数组必须已初始化且长度足够，否则抛
ArrayStoreException或IndexOutOfBoundsException - 对基本类型数组（如
int[]）优势最明显；对象数组复制只拷贝引用，不触发 clone 或构造函数
真正容易被忽略的是：所有 System 类方法都是静态且 final 的，无法 mock —— 单元测试中涉及时间、环境、退出逻辑时，必须通过包装类或接口抽象，否则只能用 PowerMock（不推荐）或迁移到 java.time.Clock 等可注入设计。
