上一篇【第05篇】项目结构与第一行代码——jvmgo 项目骨架搭建下一篇【第07篇】Entry 接口设计——类路径的积木块摘要写一个 JVM第一件要解决的事就是去哪儿找 class 文件有意思的是Java 虚拟机规范并没有规定虚拟机该从哪里寻找类——这是留给实现者的自由。Oracle 的 JVM 用的是类路径classpath方案我们的 jvmgo 也照抄这套。本文讲透类路径的三大组成部分启动类路径 / 扩展类路径 / 用户类路径、-classpath选项的各种用法、Windows 分号与 Linux 冒号的分隔符差异、Java 6 引入的通配符lib/*以及一个反直觉的结论为什么你可能听说过 CLASSPATH 环境变量但绝大多数情况下不该用它。一、为什么需要类路径HelloWorld 背后的隐形依赖先看一个你可能没注意过的事实。我们的 HelloWorld 只有 5 行代码publicclassHelloWorld{publicstaticvoidmain(String[]args){System.out.println(Hello, world!);}}编译后只有一个HelloWorld.class。看起来干干净净对吧但 JVM 要运行它实际上得加载几十上百个类【运行 HelloWorld 实际需要加载的类部分】 HelloWorld ← 我们自己写的1 个 │ ├─ java.lang.Object ← 所有类的父类必须有 ├─ java.lang.String ← main 的参数 String[] args ├─ java.lang.String[] ← 数组类型本身也是类 ├─ java.lang.System ← System.out 用到 │ └─ java.io.PrintStream ← System.out 的类型 │ └─ java.io.FilterOutputStream │ └─ java.io.OutputStream │ └─ java.lang.Object ├─ java.lang.StringBuilder ← 字符串拼接会被编译成 StringBuilder ├─ java.lang.AbstractStringBuilder ├─ java.lang.CharSequence ← 接口 └─ ... 还有 JDK 内部的启动类、异常处理类等想想看加载HelloWorld之前要先加载它的父类java.lang.Object调用main()之前要准备参数数组得加载java.lang.String和String[]把字符串打印到控制台得加载java.lang.System、java.io.PrintStream……层层依赖一环扣一环。那么问题来了这些类在磁盘的哪个角落HelloWorld.class在你当前目录这个好找但java.lang.Object在哪在 JDK 的jre/lib/rt.jar这个压缩包里如果你用了第三方库比如 commons-lang3它们的 jar 包又在lib/目录下JVM 需要一个统一的机制来定位这些散落各处的 class 文件——这就是类路径。重点类路径本质上是一份搜索清单。JVM 要加载一个类时就按这份清单挨个地方去找找到第一个匹配的就用。二、类路径的三大来源Oracle 的 JVM 把类路径分成三部分按搜索的先后顺序排列【类路径的三大组成部分】 ┌─────────────────────────────────────────────────────────┐ │ 类路径 │ │ (Classpath) │ │ │ │ ① 启动类路径 ② 扩展类路径 ③ 用户类路径 │ │ Bootstrap Classpath Extension Classpath User Classpath│ │ ┌────────────────┐ ┌────────────────┐ ┌───────────┐ │ │ │ jre/lib/* │ │ jre/lib/ext/* │ │ 默认 . │ │ │ │ │ │ │ │ │ │ │ │ · rt.jar │ │ · 扩展包 │ │ · 你的类 │ │ │ │ · resources │ │ · 本地化jar │ │ · 第三方库 │ │ │ │ · charsets │ │ │ │ │ │ │ │ · ... │ │ │ │ │ │ │ └────────────────┘ └────────────────┘ └───────────┘ │ │ 优先级最高 优先级中 优先级最低 │ │ │ │ 搜索顺序① → ② → ③ 找到了就停止 │ └─────────────────────────────────────────────────────────┘类路径默认位置装的是什么能改吗启动类路径jre/lib/Java 标准库主要都在rt.jar里可以用-Xbootclasspath很少用扩展类路径jre/lib/ext/Java 扩展机制的类一般不改用户类路径当前目录.我们自己写的类 第三方库用-classpath/-cp指定rt.jar 是个什么来头rt.jar是Runtime的缩写位于$JAVA_HOME/jre/lib/rt.jar。它是 Java 核心类库的打包文件大小约 60MBJDK 8里面塞了大约 2 万个类# 看看 rt.jar 里有什么cd$JAVA_HOME/jre/lib jar tf rt.jar|head-20# 输出节选java/lang/Object.class java/lang/String.class java/lang/System.class java/lang/Integer.class java/lang/Thread.class java/util/ArrayList.class java/util/HashMap.class java/io/PrintStream.class...# 统计有多少个类jar tf rt.jar|wc-l# 约 20000重点我们的 jvmgo 运行时必须能加载 rt.jar 里的类。所以启动类路径是三块里最关键的——没有它连java.lang.Object都找不到程序根本跑不起来。搜索顺序很重要为什么顺序重要举个经典的坑// 你自己写了一个 java.lang.String作死行为packagejava.lang;publicclassString{// ...}你编译好放进 classpath然后运行程序。你觉得 JVM 会用你写的 String 吗不会。因为启动类路径rt.jar优先级最高JVM 先在那里找到了正牌的java.lang.String就直接返回了根本不会去你的用户类路径里找。这就是双亲委派模型在类路径层面的体现——核心类库永远优先防止被恶意/误操作替换。三、-classpath / -cp 选项详解用户类路径的默认值是当前目录.。但通常我们需要指定更复杂的位置这时就用-classpath简写-cp。基本用法# 指定目录java-cppath\to\classes HelloWorld# 指定 JAR 文件java-cppath\to\lib1.jar HelloWorld# 指定 ZIP 文件是的zip 也行java-cppath\to\lib2.zip HelloWorld指定多个位置用分隔符把多个路径串起来# Windows用分号 ;java-cppath\to\classes;lib\a.jar;lib\b.jar;lib\c.zip HelloWorld# Linux / Mac用冒号 :java-cppath/to/classes:lib/a.jar:lib/b.jar:lib/c.zip HelloWorld重点这是新手最容易踩的坑之一。Windows 用分号;类 UNIXLinux/Mac用冒号:。写错了 JVM 会把整串当成一个路径然后报ClassNotFoundException。我们的 jvmgo 会用os.PathListSeparator来自动适配不用硬编码constpathListSeparatorstring(os.PathListSeparator)// Windows 下是 ;Linux/Mac 下是 :通配符Java 6 的黑科技从 Java 6 开始可以用通配符*一次指定某个目录下的所有 JAR 文件# lib 目录下的所有 jar 都会被加入类路径java-cpclasses;lib\* HelloWorld注意几个细节细节说明写法必须是lib\*不能写成lib\*.jar是否递归不递归只匹配lib/下的 jar不含子目录匹配什么只匹配.jar和.JAR不匹配.zip顺序匹配到的 jar 顺序不确定依赖文件系统别依赖顺序【通配符匹配示意图】 lib/ ├── a.jar ✅ 匹配lib/* 会加载 ├── b.jar ✅ 匹配 ├── c.JAR ✅ 匹配大小写不敏感 ├── d.zip ❌ 不匹配通配符只认 jar ├── e.class ❌ 不匹配 └── sub/ └── f.jar ❌ 不匹配不递归子目录四、CLASSPATH 环境变量为什么不推荐除了-cp选项还可以设置CLASSPATH 环境变量来指定用户类路径# WindowssetCLASSPATHD:\classes;D:\lib\a.jar# Linux / MacexportCLASSPATH/home/user/classes:/home/user/lib/a.jar但强烈不推荐这么做。原因有三理由 1优先级问题-classpath/-cp选项的优先级更高会覆盖CLASSPATH 环境变量【优先级】 -cp 选项 CLASSPATH 环境变量 默认当前目录 . (最高) (最低)这会造成困惑你明明设了环境变量但别人用-cp跑程序时它完全不起作用排查起来很懵。理由 2全局污染环境变量是全局的。你在机器上设了 CLASSPATH会影响所有Java 程序——包括那些你不该影响的程序比如 IDE、构建工具、其他项目。理由 3不可移植你的程序换台机器跑CLASSPATH 就得重新配一遍。而-cp选项通常写在启动脚本里跟着项目走可移植性好得多。最佳实践永远用-cp选项别用 CLASSPATH 环境变量。如果非要用环境变量也只在临时测试时用别写进系统配置。五、我们的 jvmgo 要怎么实现理解了概念来看实现思路。jvmgo 的 ch02 会做这些事【ch02 类路径实现规划】 ┌─────────────────────────────────────────────────────┐ │ Classpath │ │ ┌───────────────┬───────────────┬────────────────┐ │ │ │ bootClasspath │ extClasspath │ userClasspath │ │ │ │ (jre/lib/*) │(jre/lib/ext/*)│ (-cp 或 .) │ │ │ └───────┬───────┴───────┬───────┴────────┬───────┘ │ │ │ │ │ │ │ │ 每种都是 Entry 接口的某个实现 │ │ ▼ ▼ ▼ │ │ ┌────────────────────────────────────────────┐ │ │ │ Entry 接口 │ │ │ │ readClass(className) ([]byte, Entry, error)│ │ │ │ String() string │ │ │ └────────────────────────────────────────────┘ │ │ │ │ 4 种实现 │ │ · DirEntry —— 目录形式 │ │ · ZipEntry —— JAR/ZIP 文件形式 │ │ · CompositeEntry —— 多路径组合分号/冒号分隔 │ │ · WildcardEntry —— 通配符形式lib/* │ └─────────────────────────────────────────────────────┘核心 API 设计这是 JVM 规范之外的实现细节我们参考 Oracle 的做法// 解析类路径funcParse(jreOption,cpOptionstring)*Classpath// 读取 class 文件按 启动 → 扩展 → 用户 的顺序搜索func(self*Classpath)ReadClass(classNamestring)([]byte,Entry,error)调用示例// 在 startJVM 中使用cp:classpath.Parse(cmd.XjreOption,cmd.cpOption)data,entry,err:cp.ReadClass(java/lang/Object)// 参数用斜线分隔iferr!nil{fmt.Printf(找不到 java.lang.Object: %v\n,err)return}fmt.Printf(找到 java/lang/Object.class来自%v共 %d 字节\n,entry,len(data))重点注意ReadClass的参数格式——用斜线/分隔带.class后缀。比如java.lang.Object要写成java/lang/Object.class。这跟磁盘路径的写法Windows 用反斜杠不一样是 JVM 内部的统一表示法。本篇小结类路径是 JVM 定位 class 文件的机制核心要点三大来源启动类路径jre/lib核心类库 rt.jar→ 扩展类路径jre/lib/ext→ 用户类路径默认.按此顺序搜索找到即停-cp选项可指定目录、jar、zip多个用分隔符隔开Windows 分号 / Linux 冒号通配符Java 6 支持lib/*匹配目录下所有 jar不递归、只认 jar、顺序不定别用 CLASSPATH 环境变量优先级低于-cp、全局污染、不可移植我们的实现用 Entry 接口 4 种实现Dir/Zip/Composite/Wildcard来统一抽象下一篇我们正式开始写代码——设计 Entry 接口把类路径抽象成可组合的积木块。这里会用到一个经典设计模式组合模式Composite Pattern。上一篇【第05篇】项目结构与第一行代码——jvmgo 项目骨架搭建下一篇【第07篇】Entry 接口设计——类路径的积木块