文章详情
以下为资讯详情页模板：正文区域由后台内容渲染，图片与正文将自动替换为对应文章内容。
在Java基础类库里Math、System、Runtime、Object、对象克隆、Objects 这几个名字凡是写过两年代码的人应该都能报出来。可也恰恰是这类“入门就见过”的API在代码评审和线上排障里反复出问题。我见过有人用Math.round做金额舍入负数结算时对不上账见过有人以为System.arraycopy能在数组上做深拷贝结果对象数组改一个字段全串了还见过因为Cloneable里的浅拷贝语义排查了一整天才定位到问题。这篇博客不打算把每个方法重新抄一遍而是把这几个类里最值得花时间理解的部分翻出来讲讲底层逻辑、实际用法和常见的误操作。适合准备面试、也在写真实业务代码的Java开发者如果你只是想快速确认某个方法的行为也可以直接跳到对应小节。1. 为什么说这类“入门级”API才是代码评审的重灾区1.1 背API签名是最表面的学习方式我见过不少人学习API的方式是打开一篇博客把方法签名和返回值背下来然后就觉得会了。但真正的信息量其实不在签名里而在JDK源码的注释里。每个方法声明中那些看似不起眼的约束条件往往才是生产环境里最容易出事故的地方。举几个我印象深刻的例子Math.max对NaN的处理和大多数人直觉相反其中一个参数是NaN时结果就是NaNSystem.arraycopy在源和目标数组相同且区域重叠时的行为文档里写了保证像先复制到临时区一样但很多人完全没看过Object.clone如果不实现Cloneable会抛CloneNotSupportedException这个异常名本身就在告诉你接口只是标记真正逻辑在JVM侧。这些细节只有对照源码或Javadoc才能真正理解。遇到“这个API怎么跟我想的不一样”时先点进方法体看实现再查资料这个顺序比反过来要有效得多。1.2 约定重于实现很多设计其实是“引导式”的Java标准库有很大一部分API刻意做得很克制不会替你做太多决定。比如System.gc()的语义是“建议JVM执行垃圾回收”而不是“保证回收”Cloneable接口里没有任何方法只是为了告诉Object.clone当前对象允许被拷贝Random类提供线程安全性但代价是并发场景下的竞争。这种“约定大于实现”的设计在写代码时需要额外注意。你调用API只获得了它的表面能力但没有获得它的完整语义如果不去阅读约定就会在错误的场景里用它。比如很多人把System.gc()当成“内存马上变充足”的按钮把clone()当成“深拷贝”的代名词这些都是典型的理解偏差。这也是我在后面的小节里反复强调“为什么”的原因。光知道方法名解决不了实际问题能判断出应该在什么场景下用、什么场景下坚决别用才算真正掌握了常用API。2. Math工具类最容易出错的不是数学而是精度与随机数2.1 Math.round(-1.5) 为什么不是 -2先说一个最容易让人踩坑的点Math.round(-1.5)的结果是-1而不是-2。Math.round的源码语义是floor(a 0.5)。拿-1.5代入-1.5 0.5 -1.0floor(-1.0) -1.0转成long就是-1。很多人凭直觉认为round就是“四舍五入”但负数场景下根本不是这么回事。看一张对比表会更清楚方法输入结果说明Math.round(double)-1.5-1实际是floor(x 0.5)Math.round(double)2.53向正无穷方向取整Math.ceil(double)-1.2-1.0向正无穷取整Math.floor(double)-1.2-2.0向负无穷取整Math.rint(double)2.52.0取最接近整数平局时取偶数如果业务里依赖“四舍五入”对金额做处理建议先想清楚负数特例。不要用Math.round处理几份、库存、评分这类对正负数都比较敏感的值真需要精确舍入的时候优先考虑BigDecimal。2.2 Math.abs 与 Math.min 的极端值暗礁Math.abs(Integer.MIN_VALUE)的结果是-2147483648还是它自己。原因并不神秘int范围是-2147483648到2147483647正数一侧根本装不下2147483648溢出后回到最小值。想在业务里安全地取绝对值可以先抬升类型int safeAbs (int) Math.abs((long) value);用long承接后Integer.MIN_VALUE的绝对值就能正常算出来不再发生溢出。另一个冷门但真实存在的行为是Math.min(0.0, -0.0)。在浮点数世界里0.0和-0.0是不同的值Math.min的结果是-0.0。这个差异平时很难觉察但如果你用-0.0做除法或者排序就会出现负数零干扰后续逻辑的情况。想要严格比较浮点数建议用Double.compare或Double.equals而不是依赖和Math.min。还有 NaN。Math.max(Double.NaN, 1.0)的结果是NaN。在数据清洗流程里输入一旦混入NaN比较逻辑会一路传播NaN最后得到的结果很难排查。2.3 浮点精度问题为什么不能拿 Math 算金额0.1 0.2在Java里输出是0.30000000000000004这是二进制浮点精度的固有缺陷。double和float用二进制模拟十进制小数很多十进制小数在二进制里是无限循环的跟用有限位数表示1/3一样总会丢一点精度。这带来一个直接影响涉及金额、费率、折扣的计算不要让Math类参与。就算你用Math.round(new BigDecimal(0.1).add(new BigDecimal(0.2)))精度问题也已经在构造参数时发生了。正确做法是从字符串构造BigDecimal a new BigDecimal(0.1); BigDecimal b new BigDecimal(0.2); BigDecimal sum a.add(b);可以看到结果就是精确的0.3。如果非要从0.1这个double字面量出发也应该用BigDecimal.valueOf(0.1)它内部会先转成字符串表示从而避开二进制误差。2.4 随机数的正确选择Math.random 在并发下没那么合适Math.random()的实现方式是持有一个静态的Random实例每次调用都走同一个实例的nextDouble()。Random本身是线程安全的多线程调用不会出错但它的线程安全依赖对种子进行原子更新并发量一上来多个线程会在同一条更新路径上竞争吞吐量会明显下降。如果应用里有大量并发随机数需求尽量用ThreadLocalRandomdouble v ThreadLocalRandom.current().nextDouble();它在线程内部维护独立随机数状态避免跨线程竞争。需要密码学安全强度的随机数时比如生成密钥、Token再用SecureRandom。SecureRandom的构造和产生随机数的过程会消耗更多系统资源但也只有它适合安全敏感场景。需求和工具匹配这比“谁更快”更重要。3. System类点开源码之前你可能低估了它3.1 计时currentTimeMillis 与 nanoTime 的目标完全不同System.currentTimeMillis()返回的是从 Unix 纪元到当前的毫秒数它是墙上时钟时间会随着系统时间调整而变化。如果机器上了 NTP 服务时间突然跳变这个值就会跳变。它适合用来记录“今天是哪天”“这个事件发生在什么时候”。System.nanoTime()返回的是某个任意起点的纳秒数这个起点不确定甚至不同 JVM 进程里都不一样因此它不适合用来计算真实时间戳。但它适合测量时间间隔因为它保证在同一个 JVM 进程内是单调递增的在绝大多数平台上。写性能测试和超时控制时用它更可靠long start System.nanoTime(); // 执行被测逻辑 long costNanos System.nanoTime() - start;一个常见的误用是用来计算耗时时用currentTimeMillis。如果恰好在测量中间系统时间被校准耗时就会变成负值或者异常大。虽然看到负耗时的概率不高但标准做法一定是nanoTime。3.2 System.arraycopy 为什么比 for 循环快System.arraycopy是 native 方法底层可以靠近内存操作甚至利用平台层面的批量拷贝指令来加速。自己写 for 循环逐个赋值如果数组元素很多性能差距会非常明显。它有一个实用特性当源数组和目标数组是同一个数组时它会先处理重叠问题保证拷贝结果等价于先复制到临时数组再做第二次拷贝。这比手写循环更安全。Arrays.copyOf内部也依赖System.arraycopy比如Arrays.copyOf(T[] original, int newLength)会先创建新数组再调用arraycopy复制元素。集合框架里的某些扩容也走它。我在代码里常见的习惯是拷贝基础类型数组或已知数组大小时直接用System.arraycopy可读性好且不容易出错。但要注意一个限制arraycopy对对象数组来说仍是浅拷贝。它把引用复制到新数组引用指向的对象本身不会复制。数组里的某个可变对象被修改新旧两个数组都会看到变化。3.3 System.gc() 线上慎用不是礼貌建议而是风险操作System.gc()的文档语义是“建议 JVM 执行垃圾回收”听起来像是温和的请求但现实没那么友好。在很多垃圾回收器实现里调用它会直接触发 Full GC而 Full GC 往往伴随着较长的 Stop The World 停顿。线上服务如果频繁调用结果就是线程卡顿、超时、甚至雪崩。以前处理过一个案例某服务每隔几分钟调一次System.gc()运维观察到业务高峰时段持续出现几十毫秒到上百毫秒的停顿GC 日志里的 Full GC 次数异常高。当时直接建议去掉这行代码并建议在启动参数加上-XX:DisableExplicitGC来禁止代码里显式触发 GC停顿立刻大幅下降。平时想了解 JVM 内存状态优先用jcmd、jstat这类诊断工具程序内部真的需要触发 GC 做测试时也要充分评估停顿风险不能写进正常业务路径。3.4 环境属性与环境变量别混为一谈System.getProperty(user.home)读取的是 Java 系统属性来源包括-D启动参数、类路径里的一些配置以及 JVM 内置属性。System.getenv(HOME)读取的是操作系统环境变量。两套数据的来源和覆盖方式完全不同。生产环境里有人会用System.getenv读敏感配置但环境变量在容器平台比想象中容易泄露日志、进程信息里都可能有它的痕迹。也有人用System.getProperty拼文件路径比如String path System.getProperty(user.home) /app.log;这在 Linux 上没问题但到了 Windows 上就变成C:\Users\xxx/app.log分隔符混用容易踩坑。更稳妥的写法是用Paths.get(System.getProperty(user.home), app.log)。另外System.identityHashCode(obj)也值得记住。它返回对象在“未重写 hashCode 时”应有的身份哈希值不受equals/hashCode重写影响。在分析对象缓存、判断两个引用是否指向同一对象时它可以作为辅助手段。4. Runtime类少数能直接操纵JVM进程信息的窗口4.1 为什么 Runtime 获取实例不用 newRuntime的构造方法是私有的只能通过Runtime.getRuntime()拿到单例。这是因为进程级信息属于整个 JVM没有必要为每个调用方创建独立实例同一进程内多个Runtime实例反而会造成语义混乱。这个单例现在依然是查看 JVM 进程信息的主要入口和 Java 9 引入的ProcessHandle互补。Runtime runtime Runtime.getRuntime();拿到实例后能做什么可以看 CPU 核数、内存状态也可以关停 JVM、注册钩子、执行外部命令。每个能力都是进程级的权限很大使用时务必谨慎。4.2 availableProcessors 与线程池核心线程数Runtime.getRuntime().availableProcessors()返回的是当前 JVM 可用的逻辑处理器数量也就是常说的 CPU 核数。线程池设置核心线程数时最基础的公式就是基于它CPU 密集型任务通常用cpu 1IO 密集型任务可以用2 * cpu 1具体还要靠压测修正。这里有一个生产环境常见的坑老版本 JVM 在容器里运行时availableProcessors()可能返回宿主机全部核心数而不是容器被分配的核心数。比如容器只分配了 2 核但 JVM 读到宿主机的 32 核线程池直接按 33 个线程创建容器被压垮。Java 8u191 之后默认启用了容器 CPU 感知但老版本升级前还是要注意这个问题。写代码时也不要到处硬编码availableProcessors()在构造函数参数里注入一次方便测试时替换成小数值。4.3 优雅停机addShutdownHook 的注册与边界Runtime.getRuntime().addShutdownHook(Thread hook)允许注册一个在 JVM 关闭阶段执行的线程。典型的应用场景是保存内存缓存到磁盘、清理临时文件、通知注册中心下线、关闭数据库连接池。Runtime.getRuntime().addShutdownHook(new Thread(() - { cache.flush(); System.out.println(cache flushed on shutdown); }, shutdown-flusher));使用时有几个边界需要记住多个 Shutdown Hook 是并行执行的顺序不保证因此不要在钩子里依赖另一个钩子的结果钩子线程里不要做重量级操作JVM 关闭阶段留给它的时间不多System.exit()会触发钩子但Runtime.halt()立即终止 JVM不会执行钩子钩子里再次调用addShutdownHook或启动新线程可能出现不可控行为。生产环境的优雅停机最好结合运维的终止信号处理流程程序内部只负责把关键状态落盘和释放资源不要去尝试重启线程或依赖外部服务。4.4 exec() 的外部进程调用最容易被忽略的 IO 阻塞Runtime.getRuntime().exec(top -b -n 1)会启动一个外部进程并返回Process对象。但真正容易出错的是如果你马上调用process.waitFor()主线程会阻塞等待外部进程结束而外部进程的输出会写入管道缓冲区。当输出内容超过管道缓冲容量通常是 4KB 到 8KB外部进程会阻塞在写输出上无法正常退出结果你的主线程和外部进程互相等待肉眼看起来就是“程序卡死了”。正确做法是先让两个流被消费掉Process process new ProcessBuilder(top, -b, -n, 1) .redirectErrorStream(true) .start(); // 把输出读出来避免缓冲区阻塞 try (BufferedReader reader new BufferedReader( new InputStreamReader(process.getInputStream()))) { String line; while ((line reader.readLine()) ! null) { // 处理输出 } } int exitCode process.waitFor();这里用了ProcessBuilder而不是直接exec(String)原因是exec(String)会按空格拆分命令遇到带空格的路径或参数很容易出问题ProcessBuilder接受参数列表更可控。另一个技巧是redirectErrorStream(true)把错误流和标准输出合并成一个流只消费一个流就够了。4.5 内存监控三兄弟maxMemory、totalMemory、freeMemoryRuntime提供三个内存相关方法maxMemory()返回 JVM 能使用的最大堆内存对应启动参数-XmxtotalMemory()返回当前已经从操作系统申请到的堆内存这个值会随着 JVM 需要增长而增长也可能在 GC 后降低freeMemory()返回当前堆中尚未使用的部分。一个很常见的误解是把totalMemory() - freeMemory()当成 JVM 实际占用内存其实它只能表示当前堆内已使用量。JVM 自身代码、元空间、线程栈、GC 内部数据结构等大量内存根本不在这三个方法统计范围内。所以做监控告警时要配合ManagementFactory里的内存池 MXBean 一起看不能只依赖 Runtime。这三个方法最适合用在压测脚本里观察“程序是否还能撑住”不适合直接作为生产监控的唯一指标。5. Object类与对象克隆从契约到深浅拷贝的完整链路5.1 toString、equals、hashCode 的契约为什么必须一起看Object是所有类的父类也是最容易被忽略的类。toString()的默认实现是类名十六进制哈希值比如com.demo.User1a2b3c4d。如果自定义对象没重写它日志里永远是一串地址排查问题时就只能靠 IDE 去展开对象图非常低效。equals和hashCode是契约关系两个对象通过equals判断相等时它们的hashCode必须相等反过来hashCode相等不代表equals相等。这个规则直接决定了HashMap、HashSet等散列容器的行为。重写equals时同时重写hashCode否则对象放进HashMap会出现能找到逻辑相等对象却查不到值的尴尬局面。一个规范的重写例子Override public boolean equals(Object o) { if (this o) return true; if (o null || getClass() ! o.getClass()) return false; User user (User) o; return Objects.equals(name, user.name) Objects.equals(age, user.age); } Override public int hashCode() { return Objects.hash(name, age); }注意getClass() ! o.getClass()这种写法要求类型严格一致。如果改用instanceof子类对象和父类对象可能被判定为相等而它们的hashCode又不一样很容易破坏对称性规则。5.2 clone() 与 Cloneable浅拷贝的真相clone()在Object里是protected native方法逻辑由 JVM 实现而不是普通的 Java 代码。它做的事情非常朴素在当前对象的内存布局上把基本类型和引用值原样复制一份。对于引用类型字段它复制的是“引用”不是引用指向的对象。换句话说Object 层面的clone()就是浅拷贝。只有当你实现了Cloneable接口clone()才被允许执行否则 JVM 会抛CloneNotSupportedException。Cloneable里没有任何方法它只是一个标记告诉 JVM “这个类的实例可以被克隆”。看一个典型代码public class User implements Cloneable { private String name; private ListString tags new ArrayList(); Override public User clone() { try { return (User) super.clone(); } catch (CloneNotSupportedException e) { throw new AssertionError(e); } } }这样写完后clone()得到的User对象里name是复制后的新引用字符串不可变问题不大但tags仍然指向原来那个ArrayList。修改副本的tags原对象的tags也会改变。这就是浅拷贝引发脏数据的根因。5.3 深拷贝的三种实现方式与取舍实现深拷贝有三种主流方案方案一重写 clone手动复制可变字段Override public User clone() { try { User copy (User) super.clone(); copy.tags this.tags null ? null : new ArrayList(this.tags); return copy; } catch (CloneNotSupportedException e) { throw new AssertionError(e); } }这种方式直观但要人工检查每个可变字段漏一个就是隐患。方案二序列化深拷贝类实现Serializable用ObjectOutputStream写入字节数组再读回来得到一个新对象。它能把整张对象图都复制一遍但代价很大性能低、transient字段不复制、静态字段不复制、并且绕过构造器任何构造器里的约束校验都不会执行。生产环境里除非迫不得已我不推荐这条路。方案三显式拷贝构造器 / Builder / 工厂方法public User(User source) { this.name source.name; this.tags source.tags null ? null : new ArrayList(source.tags); }这可能是最容易被忽略但最稳妥的方式。它的意图直白字段逐个赋值时能看清哪些需要深拷贝而且构造器里依然可以执行校验逻辑。相比之下clone 的语义模糊稍不注意就出现引用共享。5.4 什么时候我建议你别用克隆Cloneable 和 clone 在现代 Java 工程里越来越边缘化原因很现实clone 的深浅拷贝语义依赖当前类如何实现调用者根本无法从方法签名判断clone 不调用构造器对象可能跳过约束检查与 final 字段冲突严重final 字段在 clone 里重新赋值很麻烦大量框架和库根本不依赖 clone而是用拷贝构造器、BeanUtils 或序列化。如果对象创建成本很低直接 new 一个新对象手动设置字段比 clone 更可控。只有当对象建设成本很高或者框架强制要求 clone 时才值得碰它。6. Objects工具类把空安全写进日常代码6.1 requireNonNull让空指针在入口处就暴露Objects.requireNonNull(T obj)是 Java 7 引入的工具方法作用非常简单参数为 null 时抛NullPointerException否则返回原对象。它最重要的价值不是“减少判空代码”而是让非法输入尽早暴露而不是一路传下去等真正使用时再爆一个不好定位的NPE。构造函数或 setter 里特别适合用它public User(String name) { this.name Objects.requireNonNull(name, name must not be null); }这样对象创建失败的速度非常快错误信息里还带上了字段名。Java 9 额外提供了requireNonNullElse(T obj, T defaultObj)和requireNonNullElseGet(T obj, Supplier? extends T supplier)用于“允许为空但有默认值”的场景。6.2 equals 与 deepEquals处理 null 和数组的两种姿势直接写a.equals(b)时如果a是 null就立刻空指针。Objects.equals(a, b)内部先判断引用相等再判断非空然后才调用equals所以它天然支持两端都为 null 的情况返回 true一端为 null 时返回 false。推荐在任何需要比较两个对象的地方都优先用它。Objects.deepEquals(a, b)更进一步它能处理数组。Objects.equals(new int[]{1,2}, new int[]{1,2})返回 false因为两个数组对象引用不同deepEquals则能深入比较数组中每个元素甚至多维数组。重写equals时如果要比较数组字段建议直接用它。两个方法在重写 equals 时也有实际意义return Objects.deepEquals(tags, other.tags);可以少写很多循环和数组工具类的调用。6.3 hashCode、toString、compare 等辅助方法Objects.hashCode(Object o)处理了 null 情况null 返回 0。重写 hashCode 时组合多个字段可以直接Objects.hash(name, age)它内部把参数当成数组计算哈希比手动拼字符串可靠得多。Objects.toString(Object o, String nullDefault)也很实用日志里经常有“对象可能为 null但 null 时想打印默认值”的场景。用三目运算符写起来不够干净这个工具方法一目了然。isNull和nonNull更多用于 Stream 管道里list.stream().filter(Objects::nonNull).collect(Collectors.toList());Java 9 以后的checkIndex、checkFromToIndex系列是为集合、数组的越界检查设计的更适合底层库代码普通业务里用得少但知道存在即可遇到手写边界检查时可以用。7. 一次由浅拷贝引发的串改事故从日志到根因的完整复盘7.1 事故现场请求A的筛选条件“穿越”到了请求B前段时间同事拉我一起看一个诡异问题。一个配置中心服务缓存了一份“默认查询条件”的对象。业务请求过来后先取出缓存对象调用clone()复制一份再往副本里填充本次请求的筛选条件。因为每个请求都复制了一份设计上不应该互相干扰。上线后却发现A 请求设置的筛选条件偶尔会出现在 B 请求的结果里。数据串了而且没有任何规律重启后又恢复过一段时间再次出现。7.2 排查链路从ThreadLocal到缓存地址再到clone实现排查过程按下面这条链路推进怀疑 ThreadLocal 没清理检查上下文工具类发现代码根本没有用 ThreadLocal排除。怀疑并发容器缓存结构是CopyOnWriteArrayList读多写少且没有主动 remove 操作容器本身不太可能串数据。打印日志对比 identityHashCode在请求处理前后把缓存对象、当前对象、以及当前对象内部ListString字段的内存地址都打出来。结果很清晰两个请求的当前对象identityHashCode 不同说明clone()确实生成了新对象但两个请求里list字段的 identityHashCode 完全一样。看 clone 实现一查代码问题立刻暴露。Override protected Object clone() { try { return super.clone(); } catch (CloneNotSupportedException e) { throw new RuntimeException(e); } }标准的浅拷贝。clone()复制了User对象但List字段还是同一个引用。第一个请求往list里 add 数据第二个请求拿到的当然是与第一个请求共享的同一份list。7.3 修复与规范深拷贝从来不是一句 clone() 就能交代的修复很简单把List字段在 clone 时新建一份Override public User clone() { try { User copy (User) super.clone(); copy.tags this.tags null ? null : new ArrayList(this.tags); return copy; } catch (CloneNotSupportedException e) { throw new RuntimeException(e); } }但真正要反思的是整个项目里不能只有这一个类记得深拷贝。我把这个案例沉淀成一条规范凡是可被多个调用方修改的对象要么确保它只有一个所有者要么保证多份副本之间完全不共享可变引用。排查这类问题我一直有个习惯先把“复制了没有”搞清楚再去看并发和缓存。HashMap 的拷贝构造器、ArrayList 的拷贝构造器、Arrays.copyOf这些方法表面看都能“复制”但统统是浅拷贝内部对象依然是共享的。提交代码前凡是带集合字段的对象复制逻辑我都会临时写一段测试改一下副本的叶子节点字段再看原对象是否跟着变。这一招在代码评审和自测里都极其好用也推荐你试试。特别提醒：考试时间、报名批次等安排如有调整，以河南省应急管理厅及官方考点最新通知为准。
