如何使用 System 类获取当前时间戳、环境变量及手动触发 GC 建议
System.currentTimeMillis()获取毫秒时间戳,但受系统时钟调整影响,可能导致时间不连续或回退,不适合测量耗时;getenv()读取环境变量,进程启动后快照固定,无法反映后续变化;gc()仅建议JVM回收垃圾,非强制命令,生产环境应避免频繁调用,以免影响系统性能。使用这些方法需注意其特性与局限性。
Ja va 的 System 类里藏着几个挺实用的静态方法,能帮你快速拿到当前时间戳、读环境变量,或者给 JVM 提个“该收垃圾了”的建议——注意,仅仅是建议,不是命令。下面拆成三个点来聊聊用法和该注意的坑。
获取当前时间戳(毫秒级)
System.currentTimeMillis() 返回的是从 1970 年 1 月 1 日 UTC 零点开始到现在的毫秒数,这东西常被拿去计时、打日志或者生成简单的唯一 ID。但它有个小脾气:它是系统时钟的“墙上时间”,如果你的电脑手动调了时间或者 NTP 同步了一把,这个值会跟着跳。所以真要搞高精度的性能测量,还是用 System.nanoTime() 更靠谱——纳秒级,单调递增,不受时钟调整干扰。用法也简单:long ts = System.currentTimeMillis(); 一行搞定。
读取环境变量
System.getenv() 是去拿操作系统层面的环境变量,两种常用姿势:传个名字进去,拿到对应的值(比如 System.getenv("PATH")),没有就返回 null;或者空调用,返回一个不可修改的 Map,里面是所有环境变量的快照。需要留意一点:Ja va 进程启动的那一刻,环境变量就被“拍了个照”,之后哪怕你在系统里改了,这个快照也不会更新。所以想读动态变化的环境变量?这条路走不通。
发出 GC 建议(非强制)
System.gc() 本质上是个“建议”,告诉 JVM:“嘿,你看看要不要清理一下垃圾?”但 JVM 完全可以不搭理它,尤其在用了 G1、ZGC 这类现代垃圾收集器之后,调度策略越来越自主,更不会给面子。频繁调用反而可能打乱 JVM 自己的节奏,拖慢性能——生产环境里尽量别主动调它。唯一能想到的合理场景是调试时排查内存泄漏,手动触发观察下对象有没有被回收。顺便说一句,它跟 Runtime.getRuntime().gc() 是同一个意思。











































