刚学 Java 的时候很多人都会在写 import 时产生一个疑惑java.util.ArrayList要手写导入为什么String、Math、Exception一次都没见人写过 import是不是 IDE 在后台偷偷帮我补了真不是 IDE 的功劳而是 Java 编译器默认就把java.lang包里的所有公开类全部给你导入了。这个包是 Java 语言规范钦定的核心包里面躺着Object、String、Integer、Math、System、Class这些天天都在用的基础类型。这篇文章就从一个实际开发者的角度把java.lang的身份、自动导入机制、常用类型、实战用法以及容易踩的坑讲透不管是刚入门的新手还是在写业务代码的熟手都能从中找到对自己有用的信息。1. java.lang 的“免 import”特权到底从哪来1.1 语言规范给它的特殊待遇Java 语言规范JLS里有一条规定每个编译单元都会隐式导入java.lang包中所有的 public 类型。这句话等于官方直接告诉你java.lang不是普通包它是被写进语法的“亲儿子”。代码里写不写import java.lang.*;效果都一样因为编译器默认把这张地图铺好了。这一点从包的位置也能看出来。java.lang位于整个 Java 技术体系的最底层其他包比如java.util、java.io、java.net都是在它的基础上搭建的。java.util里的ArrayList再常用编译器也不会自动帮你导入必须显式声明。原因很简单语言规范只给java.lang开小灶其他包靠的是开发者自己管理。理解这一点很多初学时的疑问就能解开——不是 IDE 智能也不是同一个包的关系纯粹是规范层面的特殊待遇。1.2 隐式导入发生在哪个阶段隐式导入发生在编译阶段而且发生在javac构建符号表的过程中。写一行代码之前源码里没有任何import java.lang.*;但编译器在处理类型名时会先把java.lang下的所有公开顶层类型当作候选符号。比如你写String s hello;编译器能在符号表里找到java.lang.String所以不会报“找不到符号”。这个机制很像是系统默认给你配了一条环境变量你不用每次敲命令都手动指定路径。import java.util.*则像是临时往环境变量里追加一个路径。编译结束之后这条“环境变量”就不起作用了真正参与运行的是编译后生成的全限定名。后面我会专门讲运行时到底发生了什么这里先记住结论java.lang的自动导入是纯编译期的行为不是运行时行为。2. import 被隐藏后编译器和运行时分别发生了什么2.1 import 是编译期概念运行时只看全限定名这是我当年花了很久才想明白的点。import语句在编译完成后就相当于不存在了因为 class 文件里保存的从来不是简单类名而是完整限定名。看个例子import java.util.ArrayList; public class Demo { public static void main(String[] args) { ArrayListString list new ArrayList(); String s list.get(0); System.out.println(s); } }对这段代码执行javap -c Demo你能在字节码里看到类似java/util/ArrayList和java/lang/String这样的完整路径。换句话说不管是显式导入的java.util.ArrayList还是隐式导入的java.lang.String编译完成后体现出来的形式没有区别全是完整类名。这个认知能解释一个常见面试题写了import是不是就会触发类加载答案是根本不会。类的加载时机由字节码指令决定比如遇到new指令、调用静态方法、访问静态字段才会触发对应类型的初始化。import在编译期就结束了跟运行时类加载毫无关系。2.2 类型解析优先级当同名类出现时听谁的既然java.lang是隐式导入那会不会和显式导入、普通包里的类产生冲突Java 规范对类型解析有一套明确顺序当前编译单元里声明的顶层类型优先其次是在文件中显式写到 import 的单类型导入再次是按需导入也就是import xxx.*;这种通配导入java.lang的隐式导入可以理解成一个默认存在的按需导入。所以当你自己写的项目中存在一个类恰好和java.lang里的类同名时编译器不见得会报错它可能直接解析到你自定义的这个类上。这种默认行为容易埋雷我在第 5 节会详细展开怎么处理和规避。2.3 模块化时代下 java.lang 依然特殊从 JDK 9 引入模块系统开始java.lang被收进了java.base模块。模块化之后有一个明显变化所有模块都依赖java.base但引用它的类型时依然不需要写模块依赖声明这是java.base和java.lang的双重特权。所以对普通业务开发者来说写String、写System、写Exception体验和以前完全一致。不过有两点值得注意。第一java.base模块对外暴露的包不止java.lang还包括java.util、java.io等全部基础 API这些包里的类照旧需要显式 import并不会因为模块化而自动导入。第二JDK 内部有些类藏在java.lang包里但不是 public 的比如StringLatin1普通代码碰不到这些是内部实现细节。3. 快速掌握 java.lang 里的高频类型3.1 Object所有类的根java.lang.Object是整个对象体系的老大Java 里的每一个类都直接或间接继承自它。这意味着所有对象默认拥有toString、equals、hashCode、getClass、wait、notify等方法。很多人学到这里只是把方法背下来了实战里却容易忽略它们的默认行为。比如toString默认输出的是“类名十六进制hashCode”业务日志里如果调用一个没重写toString的对象打出来就是一串毫无意义的内容。equals默认比较的是引用地址两个字段完全一样的对象各new一次用equals比较竟然是false。这些默认行为本身没错但业务类里如果涉及比较和日志最好按需重写toString、equals、hashCode三个方法。注意重写equals必须同时重写hashCode否则在HashMap、HashSet里会出现明明“相等”却查不到数据的诡异问题。3.2 字符串三兄弟String、StringBuilder、StringBufferString是不可变类型每次拼接都会产生新对象。以前老代码喜欢写String result a b c;如果在一个循环里反复拼接会在循环内部新建大量中间对象性能很差。这种场景的正确做法是使用StringBuilder。StringBuilder是非线程安全的可变字符序列绝大多数单线程场景足够了。StringBuffer是它的线程安全版本方法级加了synchronized代价是性能略低。开发时别一看到“线程安全”四个字就无脑选StringBuffer先想清楚自己是不是真的要跨线程操作同一个字符串对象多数业务方法都在单线程内完成拼接用StringBuilder更合理。JVM 对字符串拼接做了很多优化。比如直接用拼接字符串常量编译期可能直接算好结果用拼接包含变量的字符串新版 JDK 底层会通过invokedynamic优化为更高效的实现。所以不用走极端到禁止写但是循环内拼接依然建议手动用StringBuilder特别是循环次数不确定且可能很大的场景。3.3 包装类与自动装箱的缓存陷阱java.lang里还有一批为基本类型准备的包装类Integer、Long、Short、Byte、Character、Float、Double、Boolean。自动装箱和拆箱让int和Integer之间的转换看起来没有边界但底层有个缓存机制经常让人踩坑。Integer默认缓存了-128到127之间的所有值。也就是说这个范围里的整数走自动装箱时返回的是同一个缓存对象超出这个范围则会new一个新对象。于是下面这段代码看起来匪夷所思Integer a 100; Integer b 100; System.out.println(a b); // true Integer c 200; Integer d 200; System.out.println(c d); // false原因就是100命中了缓存200没有。Long也有类似的缓存机制。处理包装类比较时一律用equals或直接拆箱成基本类型比较不要依赖。这个坑在读取配置、解析 JSON 数字时特别容易触发值刚好落在 127 以内没问题一超过就出现“同一个请求处理两次结果不一致”的假象排查起来特别费劲。3.4 System、Math、Runtime三个高频工具类System类常用到几乎没什么存在感System.out、System.err是标准输出流System.currentTimeMillis()拿当前时间戳System.arraycopy做数组复制System.gc()建议 JVM 执行垃圾回收。System.nanoTime()用于测量短时间间隔精度更高但是不能用来换算绝对时间。Math类提供了max、min、abs、pow、sqrt、random等静态数学方法。Math.round的返回值类型需要留意传入float返回int传入double返回long签名不同容易记混。Runtime类是一个典型的单例类通过Runtime.getRuntime()获取实例能拿到 JVM 内存总量、空闲内存、可用处理器数量等信息。它和Process配合还能启动操作系统进程但日常开发中使用频率比System低很多。这几个类本身不大胜在都是静态工具用熟了能省不少事。4. 实战看 java.lang 如何融入日常编码4.1 日志拼接StringBuilder 的正确打开方式写业务代码拼日志字符串是最常见的场景。早期我见过一段代码在循环里用拼上万条数据处理日志结果接口响应时间被拖慢不少。原因就是循环里反复创建StringBuilder和中间字符串对象给垃圾回收造成了压力。优化后代码长这样StringBuilder sb new StringBuilder(1024); for (int i 0; i list.size(); i) { Item item list.get(i); sb.append(index).append(i) .append(, id).append(item.getId()) .append(, name).append(item.getName()) .append(\n); } System.out.println(sb.toString());注意这里我给StringBuilder指定了初始容量1024。这不是随手写的而是估算整个日志文本大概几百字节直接预留容量能避免拼接过程中频繁扩容。StringBuilder内部是 char 数组容量不够时默认扩容策略是旧容量两倍再加二扩容会复制数组是隐藏成本。数据量大时先估算容量再申请效果非常明显。日志系统本身也大量依赖java.lang的类比如StackTraceElement用于记录调用栈。你看到日志里那一行行at com.xxx.Class.method就是Throwable.getStackTrace()提取出来的元素这些底层机制同样藏在java.lang包里。4.2 耗时统计currentTimeMillis 与 nanoTime 的取舍性能排查时经常要统计一段代码的执行耗时。最简单的方式是前后取时间戳相减long start System.currentTimeMillis(); doSomething(); long cost System.currentTimeMillis() - start; System.out.println(cost: cost ms);currentTimeMillis返回的是从 1970 年 1 月 1 日 00:00:00 UTC 到现在的毫秒数它依赖系统时钟。系统时钟可能被修改比如 NTP 校准、手动调时间都可能导致计时结果出现负值或偏差。测量短到微秒级别的代码段时用System.nanoTime()更合适long start System.nanoTime(); doSomething(); long cost System.nanoTime() - start; System.out.println(cost: cost ns);nanoTime返回的是某个未知起点的纳秒值只能用来算差值不能拿着它关联具体时间点。在线监控场景里两种方法各有用途记录请求发生时间用currentTimeMillis做代码段性能基线测试用nanoTime。另外统计学上单次测试结果没有说服力至少要跑多轮取平均值或百分位才能反映真实性能。4.3 反射入口Class 对象为什么也在 java.lang反射是 Java 动态能力的基石而反射的入口Class类就属于java.lang。拿到Class对象常见有三种方式Class? clazz1 String.class; Class? clazz2 Class.forName(java.lang.String); Class? clazz3 abc.getClass();第一种最直接编译期就确定了第二种适合字符串形式的类名常用于配置驱动场景比如框架里根据配置类名加载实现类第三种在运行时实例上调用。Class对象提供了getName、getMethods、getDeclaredFields、getAnnotation、isInterface、isAssignableFrom等方法这些能力构成了反射、动态代理、依赖注入框架的基础。实际开发中有些同学喜欢用反射去绕过私有字段读取比如在工具类里强行读取某个类的内部状态。能实现但代价是代码可读性差、性能低而且 JDK 版本升级后私有实现一变代码就可能崩溃。能用接口和公开方法解决的尽量别靠反射必须反射时也要把setAccessible(true)的范围控制到最小并且用try-catch包好异常因为反射异常往往比普通调用更隐蔽。5. 当自动导入失灵同名类冲突的彻底解决方案5.1 如果我自己写一个 String 类会怎样有一道面试题问得比较多“能否在java.lang包下自定义一个类”答案是不建议也做不到在规范层面绕过保护。JDK 对java.lang包有完整限制自定义java.lang.String这种类名在启动时会被安全机制拦截因为系统不容许你替换核心类。这个机制是为了防止恶意代码伪装成 JDK 内部类获得不该有的权限。但你可能在一个普通包下写一个String类比如com.example.String。此时代码里写String s abc;会发生什么要分情况看。如果在同一个类里声明了局部类型、或当前编译单元里有一个自定义String编译器会优先解析到当前声明的类型于是你的变量不再是java.lang.String而是自定义类。如果在另一个类文件里引用它可能会和java.lang.String同时出现在候选集合里产生歧义或误解析。不管是哪种结果都很麻烦。5.2 用全限定名解决冲突一旦发现“我的代码里怎么找不到 String 方法了”先检查是不是引入了同名类。解决手段也不复杂在需要java.lang.String的地方写全限定名。java.lang.String realString hello;全限定名不需要任何 import因为java.lang本来就是隐式可用编译器拿到完整路径后不会再去猜。反过来如果你要访问自定义的com.example.String要么正常写 import要么也写全限定名。说白了当简单名发生冲突时唯一可靠的解释就是完整路径。还有一类冲突经常发生在java.util.Date和java.sql.Date之间。这两个类都是显式导入只要同时引入就会直接编译报错。报错其实还好办解法同样是其中一个用全限定名。真正难排查的是java.lang的同名冲突因为它是隐式导入报错信息有时候不带包名很容易让人误以为是代码本身写错了。5.3 从开发规范上彻底规避我自己平时写代码有一条硬性要求业务项目里禁止出现和java.lang、java.util高频类型同名的类。比如String、Object、Integer、System、Math、Exception这些名字不管放在哪个包下都不要用。哪怕只是包级内部使用也会给未来维护的人带来极大困惑代码评审时一眼就能看出来问题。如果实在要建模一个“用户”或“订单”业务对象命名上优先是UserInfo、OrderDetail这种带领域后缀的名字而不是User这种看起来很通用但可能撞车的短名。这里不是说不准起User而是说团队要对类名占用保持敏感公共包里的简单类名是宝贵资源别为了一时方便制造长期隐患。6. 高频疑问速查与经验心得6.1 java.lang 常见疑问对照速查表疑问结论为什么不用 import java.lang.StringJDK 编译期隐式导入了 java.lang 全部公开类型自己写 import java.lang.String 会报错吗一般不报错但没必要还容易引入歧义import 会导致类加载吗不会import 只做编译期类型解析java.lang 是默认包吗不是默认包指没有 package 声明的类所在包JDK 9 模块化后 java.lang 还能自动导入吗能它在 java.base 模块所有模块自动依赖能在 java.lang 下开发自己的类吗不能绕过 JDK 保护也不要尝试Integer 比较用 为什么结果不一致自动装箱缓存范围限制超出范围是不同对象单例类可以放在 java.lang 吗可以比如 Runtime 就是单例但业务代码别模仿这张表覆盖了我在面试和内部培训里遇到的高频问题基本能把“java.lang 到底是什么”一次聊清楚。这里多提一句不少人分不清java.lang和默认包两个概念完全不同。一个是没有package声明时所在的匿名包一个是 JDK 自带的语言基础包只是都带一个“包”字而已。6.2 这几个坑我真实踩过第一个坑是Integer缓存导致的比较问题。之前维护过一段老代码里面用Integer当Map的 key取出来之后直接用和另一个Integer比较。测试数据都集中在 20 到 100 之间跑得好好的上线后用户数据一到 500 就出问题。后来定位到是缓存范围这个机制教训很深包装类比较永远用equals别靠运气。第二个坑是toString没重写日志里刷出一堆com.xxx.User1a2b3c。当时排查一个数据回显问题看一眼日志基本是废的根本分不清是哪个用户的数据。后来我们把业务对象的toString统一为输出 id、name、关键状态字段排查效率立刻上去了。这个改动很小收益却很大。第三个坑是循环里用拼接字符串。代码看着简洁但压测时 GC 压力明显偏高。改成StringBuilder并指定合理初始容量后吞吐量提了一截。说句实在话StringBuilder的源码值得精读一遍尤其是扩容逻辑和 append 的返回机制读完后你会对“为什么推荐提前指定容量”有更直观的理解。最后再分享一个小技巧当你怀疑某个符号是不是来自java.lang时直接在 IDE 里按住 Ctrl 点一下类名跳转到的源码路径会明确写出java.lang.String或别的包路径。这个操作比死记文档快多了看几次源码你对java.lang的认识就不再是“玄学”而是一条条实打实的包路径和类定义。
刚学 Java 的时候很多人都会在写 import 时产生一个疑惑java.util.ArrayList要手写导入为什么String、Math、Exception一次都没见人写过 import是不是 IDE 在后台偷偷帮我补了真不是 IDE 的功劳而是 Java 编译器默认就把java.lang包里的所有公开类全部给你导入了。这个包是 Java 语言规范钦定的核心包里面躺着Object、String、Integer、Math、System、Class这些天天都在用的基础类型。这篇文章就从一个实际开发者的角度把java.lang的身份、自动导入机制、常用类型、实战用法以及容易踩的坑讲透不管是刚入门的新手还是在写业务代码的熟手都能从中找到对自己有用的信息。1. java.lang 的“免 import”特权到底从哪来1.1 语言规范给它的特殊待遇Java 语言规范JLS里有一条规定每个编译单元都会隐式导入java.lang包中所有的 public 类型。这句话等于官方直接告诉你java.lang不是普通包它是被写进语法的“亲儿子”。代码里写不写import java.lang.*;效果都一样因为编译器默认把这张地图铺好了。这一点从包的位置也能看出来。java.lang位于整个 Java 技术体系的最底层其他包比如java.util、java.io、java.net都是在它的基础上搭建的。java.util里的ArrayList再常用编译器也不会自动帮你导入必须显式声明。原因很简单语言规范只给java.lang开小灶其他包靠的是开发者自己管理。理解这一点很多初学时的疑问就能解开——不是 IDE 智能也不是同一个包的关系纯粹是规范层面的特殊待遇。1.2 隐式导入发生在哪个阶段隐式导入发生在编译阶段而且发生在javac构建符号表的过程中。写一行代码之前源码里没有任何import java.lang.*;但编译器在处理类型名时会先把java.lang下的所有公开顶层类型当作候选符号。比如你写String s hello;编译器能在符号表里找到java.lang.String所以不会报“找不到符号”。这个机制很像是系统默认给你配了一条环境变量你不用每次敲命令都手动指定路径。import java.util.*则像是临时往环境变量里追加一个路径。编译结束之后这条“环境变量”就不起作用了真正参与运行的是编译后生成的全限定名。后面我会专门讲运行时到底发生了什么这里先记住结论java.lang的自动导入是纯编译期的行为不是运行时行为。2. import 被隐藏后编译器和运行时分别发生了什么2.1 import 是编译期概念运行时只看全限定名这是我当年花了很久才想明白的点。import语句在编译完成后就相当于不存在了因为 class 文件里保存的从来不是简单类名而是完整限定名。看个例子import java.util.ArrayList; public class Demo { public static void main(String[] args) { ArrayListString list new ArrayList(); String s list.get(0); System.out.println(s); } }对这段代码执行javap -c Demo你能在字节码里看到类似java/util/ArrayList和java/lang/String这样的完整路径。换句话说不管是显式导入的java.util.ArrayList还是隐式导入的java.lang.String编译完成后体现出来的形式没有区别全是完整类名。这个认知能解释一个常见面试题写了import是不是就会触发类加载答案是根本不会。类的加载时机由字节码指令决定比如遇到new指令、调用静态方法、访问静态字段才会触发对应类型的初始化。import在编译期就结束了跟运行时类加载毫无关系。2.2 类型解析优先级当同名类出现时听谁的既然java.lang是隐式导入那会不会和显式导入、普通包里的类产生冲突Java 规范对类型解析有一套明确顺序当前编译单元里声明的顶层类型优先其次是在文件中显式写到 import 的单类型导入再次是按需导入也就是import xxx.*;这种通配导入java.lang的隐式导入可以理解成一个默认存在的按需导入。所以当你自己写的项目中存在一个类恰好和java.lang里的类同名时编译器不见得会报错它可能直接解析到你自定义的这个类上。这种默认行为容易埋雷我在第 5 节会详细展开怎么处理和规避。2.3 模块化时代下 java.lang 依然特殊从 JDK 9 引入模块系统开始java.lang被收进了java.base模块。模块化之后有一个明显变化所有模块都依赖java.base但引用它的类型时依然不需要写模块依赖声明这是java.base和java.lang的双重特权。所以对普通业务开发者来说写String、写System、写Exception体验和以前完全一致。不过有两点值得注意。第一java.base模块对外暴露的包不止java.lang还包括java.util、java.io等全部基础 API这些包里的类照旧需要显式 import并不会因为模块化而自动导入。第二JDK 内部有些类藏在java.lang包里但不是 public 的比如StringLatin1普通代码碰不到这些是内部实现细节。3. 快速掌握 java.lang 里的高频类型3.1 Object所有类的根java.lang.Object是整个对象体系的老大Java 里的每一个类都直接或间接继承自它。这意味着所有对象默认拥有toString、equals、hashCode、getClass、wait、notify等方法。很多人学到这里只是把方法背下来了实战里却容易忽略它们的默认行为。比如toString默认输出的是“类名十六进制hashCode”业务日志里如果调用一个没重写toString的对象打出来就是一串毫无意义的内容。equals默认比较的是引用地址两个字段完全一样的对象各new一次用equals比较竟然是false。这些默认行为本身没错但业务类里如果涉及比较和日志最好按需重写toString、equals、hashCode三个方法。注意重写equals必须同时重写hashCode否则在HashMap、HashSet里会出现明明“相等”却查不到数据的诡异问题。3.2 字符串三兄弟String、StringBuilder、StringBufferString是不可变类型每次拼接都会产生新对象。以前老代码喜欢写String result a b c;如果在一个循环里反复拼接会在循环内部新建大量中间对象性能很差。这种场景的正确做法是使用StringBuilder。StringBuilder是非线程安全的可变字符序列绝大多数单线程场景足够了。StringBuffer是它的线程安全版本方法级加了synchronized代价是性能略低。开发时别一看到“线程安全”四个字就无脑选StringBuffer先想清楚自己是不是真的要跨线程操作同一个字符串对象多数业务方法都在单线程内完成拼接用StringBuilder更合理。JVM 对字符串拼接做了很多优化。比如直接用拼接字符串常量编译期可能直接算好结果用拼接包含变量的字符串新版 JDK 底层会通过invokedynamic优化为更高效的实现。所以不用走极端到禁止写但是循环内拼接依然建议手动用StringBuilder特别是循环次数不确定且可能很大的场景。3.3 包装类与自动装箱的缓存陷阱java.lang里还有一批为基本类型准备的包装类Integer、Long、Short、Byte、Character、Float、Double、Boolean。自动装箱和拆箱让int和Integer之间的转换看起来没有边界但底层有个缓存机制经常让人踩坑。Integer默认缓存了-128到127之间的所有值。也就是说这个范围里的整数走自动装箱时返回的是同一个缓存对象超出这个范围则会new一个新对象。于是下面这段代码看起来匪夷所思Integer a 100; Integer b 100; System.out.println(a b); // true Integer c 200; Integer d 200; System.out.println(c d); // false原因就是100命中了缓存200没有。Long也有类似的缓存机制。处理包装类比较时一律用equals或直接拆箱成基本类型比较不要依赖。这个坑在读取配置、解析 JSON 数字时特别容易触发值刚好落在 127 以内没问题一超过就出现“同一个请求处理两次结果不一致”的假象排查起来特别费劲。3.4 System、Math、Runtime三个高频工具类System类常用到几乎没什么存在感System.out、System.err是标准输出流System.currentTimeMillis()拿当前时间戳System.arraycopy做数组复制System.gc()建议 JVM 执行垃圾回收。System.nanoTime()用于测量短时间间隔精度更高但是不能用来换算绝对时间。Math类提供了max、min、abs、pow、sqrt、random等静态数学方法。Math.round的返回值类型需要留意传入float返回int传入double返回long签名不同容易记混。Runtime类是一个典型的单例类通过Runtime.getRuntime()获取实例能拿到 JVM 内存总量、空闲内存、可用处理器数量等信息。它和Process配合还能启动操作系统进程但日常开发中使用频率比System低很多。这几个类本身不大胜在都是静态工具用熟了能省不少事。4. 实战看 java.lang 如何融入日常编码4.1 日志拼接StringBuilder 的正确打开方式写业务代码拼日志字符串是最常见的场景。早期我见过一段代码在循环里用拼上万条数据处理日志结果接口响应时间被拖慢不少。原因就是循环里反复创建StringBuilder和中间字符串对象给垃圾回收造成了压力。优化后代码长这样StringBuilder sb new StringBuilder(1024); for (int i 0; i list.size(); i) { Item item list.get(i); sb.append(index).append(i) .append(, id).append(item.getId()) .append(, name).append(item.getName()) .append(\n); } System.out.println(sb.toString());注意这里我给StringBuilder指定了初始容量1024。这不是随手写的而是估算整个日志文本大概几百字节直接预留容量能避免拼接过程中频繁扩容。StringBuilder内部是 char 数组容量不够时默认扩容策略是旧容量两倍再加二扩容会复制数组是隐藏成本。数据量大时先估算容量再申请效果非常明显。日志系统本身也大量依赖java.lang的类比如StackTraceElement用于记录调用栈。你看到日志里那一行行at com.xxx.Class.method就是Throwable.getStackTrace()提取出来的元素这些底层机制同样藏在java.lang包里。4.2 耗时统计currentTimeMillis 与 nanoTime 的取舍性能排查时经常要统计一段代码的执行耗时。最简单的方式是前后取时间戳相减long start System.currentTimeMillis(); doSomething(); long cost System.currentTimeMillis() - start; System.out.println(cost: cost ms);currentTimeMillis返回的是从 1970 年 1 月 1 日 00:00:00 UTC 到现在的毫秒数它依赖系统时钟。系统时钟可能被修改比如 NTP 校准、手动调时间都可能导致计时结果出现负值或偏差。测量短到微秒级别的代码段时用System.nanoTime()更合适long start System.nanoTime(); doSomething(); long cost System.nanoTime() - start; System.out.println(cost: cost ns);nanoTime返回的是某个未知起点的纳秒值只能用来算差值不能拿着它关联具体时间点。在线监控场景里两种方法各有用途记录请求发生时间用currentTimeMillis做代码段性能基线测试用nanoTime。另外统计学上单次测试结果没有说服力至少要跑多轮取平均值或百分位才能反映真实性能。4.3 反射入口Class 对象为什么也在 java.lang反射是 Java 动态能力的基石而反射的入口Class类就属于java.lang。拿到Class对象常见有三种方式Class? clazz1 String.class; Class? clazz2 Class.forName(java.lang.String); Class? clazz3 abc.getClass();第一种最直接编译期就确定了第二种适合字符串形式的类名常用于配置驱动场景比如框架里根据配置类名加载实现类第三种在运行时实例上调用。Class对象提供了getName、getMethods、getDeclaredFields、getAnnotation、isInterface、isAssignableFrom等方法这些能力构成了反射、动态代理、依赖注入框架的基础。实际开发中有些同学喜欢用反射去绕过私有字段读取比如在工具类里强行读取某个类的内部状态。能实现但代价是代码可读性差、性能低而且 JDK 版本升级后私有实现一变代码就可能崩溃。能用接口和公开方法解决的尽量别靠反射必须反射时也要把setAccessible(true)的范围控制到最小并且用try-catch包好异常因为反射异常往往比普通调用更隐蔽。5. 当自动导入失灵同名类冲突的彻底解决方案5.1 如果我自己写一个 String 类会怎样有一道面试题问得比较多“能否在java.lang包下自定义一个类”答案是不建议也做不到在规范层面绕过保护。JDK 对java.lang包有完整限制自定义java.lang.String这种类名在启动时会被安全机制拦截因为系统不容许你替换核心类。这个机制是为了防止恶意代码伪装成 JDK 内部类获得不该有的权限。但你可能在一个普通包下写一个String类比如com.example.String。此时代码里写String s abc;会发生什么要分情况看。如果在同一个类里声明了局部类型、或当前编译单元里有一个自定义String编译器会优先解析到当前声明的类型于是你的变量不再是java.lang.String而是自定义类。如果在另一个类文件里引用它可能会和java.lang.String同时出现在候选集合里产生歧义或误解析。不管是哪种结果都很麻烦。5.2 用全限定名解决冲突一旦发现“我的代码里怎么找不到 String 方法了”先检查是不是引入了同名类。解决手段也不复杂在需要java.lang.String的地方写全限定名。java.lang.String realString hello;全限定名不需要任何 import因为java.lang本来就是隐式可用编译器拿到完整路径后不会再去猜。反过来如果你要访问自定义的com.example.String要么正常写 import要么也写全限定名。说白了当简单名发生冲突时唯一可靠的解释就是完整路径。还有一类冲突经常发生在java.util.Date和java.sql.Date之间。这两个类都是显式导入只要同时引入就会直接编译报错。报错其实还好办解法同样是其中一个用全限定名。真正难排查的是java.lang的同名冲突因为它是隐式导入报错信息有时候不带包名很容易让人误以为是代码本身写错了。5.3 从开发规范上彻底规避我自己平时写代码有一条硬性要求业务项目里禁止出现和java.lang、java.util高频类型同名的类。比如String、Object、Integer、System、Math、Exception这些名字不管放在哪个包下都不要用。哪怕只是包级内部使用也会给未来维护的人带来极大困惑代码评审时一眼就能看出来问题。如果实在要建模一个“用户”或“订单”业务对象命名上优先是UserInfo、OrderDetail这种带领域后缀的名字而不是User这种看起来很通用但可能撞车的短名。这里不是说不准起User而是说团队要对类名占用保持敏感公共包里的简单类名是宝贵资源别为了一时方便制造长期隐患。6. 高频疑问速查与经验心得6.1 java.lang 常见疑问对照速查表疑问结论为什么不用 import java.lang.StringJDK 编译期隐式导入了 java.lang 全部公开类型自己写 import java.lang.String 会报错吗一般不报错但没必要还容易引入歧义import 会导致类加载吗不会import 只做编译期类型解析java.lang 是默认包吗不是默认包指没有 package 声明的类所在包JDK 9 模块化后 java.lang 还能自动导入吗能它在 java.base 模块所有模块自动依赖能在 java.lang 下开发自己的类吗不能绕过 JDK 保护也不要尝试Integer 比较用 为什么结果不一致自动装箱缓存范围限制超出范围是不同对象单例类可以放在 java.lang 吗可以比如 Runtime 就是单例但业务代码别模仿这张表覆盖了我在面试和内部培训里遇到的高频问题基本能把“java.lang 到底是什么”一次聊清楚。这里多提一句不少人分不清java.lang和默认包两个概念完全不同。一个是没有package声明时所在的匿名包一个是 JDK 自带的语言基础包只是都带一个“包”字而已。6.2 这几个坑我真实踩过第一个坑是Integer缓存导致的比较问题。之前维护过一段老代码里面用Integer当Map的 key取出来之后直接用和另一个Integer比较。测试数据都集中在 20 到 100 之间跑得好好的上线后用户数据一到 500 就出问题。后来定位到是缓存范围这个机制教训很深包装类比较永远用equals别靠运气。第二个坑是toString没重写日志里刷出一堆com.xxx.User1a2b3c。当时排查一个数据回显问题看一眼日志基本是废的根本分不清是哪个用户的数据。后来我们把业务对象的toString统一为输出 id、name、关键状态字段排查效率立刻上去了。这个改动很小收益却很大。第三个坑是循环里用拼接字符串。代码看着简洁但压测时 GC 压力明显偏高。改成StringBuilder并指定合理初始容量后吞吐量提了一截。说句实在话StringBuilder的源码值得精读一遍尤其是扩容逻辑和 append 的返回机制读完后你会对“为什么推荐提前指定容量”有更直观的理解。最后再分享一个小技巧当你怀疑某个符号是不是来自java.lang时直接在 IDE 里按住 Ctrl 点一下类名跳转到的源码路径会明确写出java.lang.String或别的包路径。这个操作比死记文档快多了看几次源码你对java.lang的认识就不再是“玄学”而是一条条实打实的包路径和类定义。
