System类核心静态方法包括：System.out.println()可重定向输出；currentTimeMillis()获系统时间戳但不适用于高精度计时；arraycopy()高效数组拷贝且做边界检查；getProperty()/getenv()区分JVM属性与环境变量；gc()仅建议回收，exit()终止JVM并触发shutdown hooks。
System类的常用静态方法及典型用途
面试官常会考察你对System类核心静态方法的掌握程度，重点不在死记硬背，而在能否结合场景说明为什么用、怎么用、有什么坑。比如System.out.println()本质是调用PrintStream对象的print方法，而System.out本身可被重定向（如用System.setOut()），这点常被忽略。
其他高频方法包括：
- System.currentTimeMillis()：获取毫秒级时间戳，注意它依赖系统时钟，不适用于高精度计时（应选System.nanoTime()）
- System.arraycopy()：比手动for循环拷贝数组更高效，且支持跨数组边界检查（会抛ArrayIndexOutOfBoundsException而非NullPointerException）
- System.getProperty()和System.getenv()：区分JVM属性与操作系统环境变量，常见考点是java.version、user.dir等内置key
System类与JVM底层机制的关联点
面试中若问“为什么System类的方法大多是native的”，就是在试探你是否理解其与JVM的绑定关系。例如System.currentTimeMillis()最终调用操作系统API（如Linux的clock_gettime()），System.identityHashCode()则直接读取对象头中的哈希码字段——这些都不是Java层能直接实现的。
需注意几个关键事实：
- System.gc()只是建议JVM执行垃圾回收，不保证立即触发；现代JVM（如ZGC、Shenandoah）对此调用基本忽略
- System.exit()会终止JVM进程，触发shutdown hooks，但不会释放本地资源（如文件句柄、JNI分配内存），需提前清理
- System.runFinalizersOnExit(true)已被废弃，因存在竞态风险，不应使用
容易踩坑的实战细节
实际编码中，System类相关操作看似简单，却常因忽略细节引发线上问题。比如日志中打印时间，误用currentTimeMillis()做耗时统计，结果受系统时钟回拨影响导致负值；又比如用arraycopy()时源数组为null，会直接抛NPE——它不校验参数对象是否为空，只校验索引范围。
几个必须留意的点：
- System.out / System.err是线程安全的，但性能较差，高并发场景下应避免频繁调用
- System.setProperty()修改的是JVM启动后的运行时属性，不影响已加载的类（如Logger配置可能已固化）
- 在容器或云环境中，System.getenv("PATH")可能为空或不可靠，优先通过配置中心或启动参数传入关键路径
延伸考点：SecurityManager与System权限控制
虽然Java 17起默认移除了SecurityManager，但部分老系统或金融类项目仍涉及相关逻辑。面试可能问：“如果启用了SecurityManager，调用System.setProperty()会发生什么？”答案是触发PropertyPermission检查，若无授权则抛SecurityException。
这类问题意在考察你对Java沙箱机制的理解深度，可补充说明：
- SecurityManager已deprecated多年，新项目无需适配，但阅读遗留代码时需识别相关checkPermission调用
- 替代方案是通过JVM参数（如-D）或外部配置管理属性，避免运行时动态修改
- 敏感操作如System.exit()、System.setSecurityManager()同样受权限约束
