前一阵子我处理一个 Java 服务启动慢的问题点完启动按钮到端口监听中间隔着十几秒干等。依赖膨胀到几百个 jar 包类加载器每次找类都要把 classpath 翻个底朝天。这个场景让我重新盯上一个老算法布隆过滤器Bloom Filter它专门适合“大量 jar 包加载时加快启动速度”这样的概率过滤问题。这篇文章会从类加载耗时点讲起把为什么用布隆过滤器、参数怎么定、代码怎么落地说清楚也把容易踩的坑一起排掉。适合被启动时间折磨的 Java 工程师也适合想深入理解类加载和布隆过滤器工程化用途的同学。1. 为什么大量 jar 包会让启动变慢1.1 启动阶段到底在等什么先说结论不是类实例化变慢而是“找类”这个动作变慢。JVM 加载类的入口是ClassLoader.loadClassJDK 的URLClassLoader拿到全限定名后会遍历 classpath 里的每个 URL。对每个 jar它先打开JarFile在 zip 文件的 central directory 里按名字查找对应 entry比如com/foo/Bar.class找到就读取并defineClass找不到就关掉继续下一个。这个过程的成本主要在磁盘 IO 和文件打开操作。几十个 jar 时还好项目一膨胀到两三百个 jar一个类的查找最坏要开 300 次文件平均也有一百多次启动阶段要加载几千个类乘上去之后耗时非常可观。我之前用 JFR 抓过一次类加载相关的文件打开次数能占整个启动期文件打开总量的七成。可以说启动慢和 jar 数量高度正相关而不是简单的 Bean 初始化问题。1.2 FatJar 场景比普通 classpath 更夸张如果项目是 Spring Boot 打成的可执行 fat jar情况会更严重。所有第三方 jar 被塞进BOOT-INF/lib外层是一个 zip 文件内部 jar 是嵌套结构。Spring Boot 需要自定义LaunchedURLClassLoader来处理这种嵌套 jar定位一个内部 entry 时无法直接利用操作系统文件系统索引必须在外层 jar 和嵌套 jar 之间做两层查找。早期的实现每次都可能涉及 zip entry 的解析查找成本比普通 classpath 高一个量级。可以这样类比普通 classpath 是书架上一排书找内容就一本一本地翻目录fat jar 等于所有书塞进一个大旅行箱每次找内容都要开箱、翻开对应那本书的目录、再翻到某一页。翻的次数一多等待感非常明显。Spring Boot 2.3 之后的JarFile索引方案对此有优化但默认场景下类路径扫描和类查找的总开销仍然和 jar 包数量强相关。2. 布隆过滤器把“从哪找”改成“不在哪找”2.1 一个位数组和几个哈希函数布隆过滤器的核心数据结构是位数组和一组哈希函数。插入元素时用 k 个哈希函数算出 k 个位置把这些位全部置为 1。查询时同样算 k 个位置只要发现任何一位为 0元素一定不在集合中如果全是 1元素可能在集合里。它给出的答案是非对称的可以百分之百确定“不在”不能百分之百确定“在”。这种“宁可误报、绝不漏报”的特性用在类加载上反而很合适。类加载场景中我需要的是快速排除大多数 jar被误判到一两个 jar最多多打开一次文件漏判才是灾难那会导致本该加载的类变成ClassNotFoundException。2.2 内存估算和误判率公式假设一个 jar 里有 n 个条目允许的误判率是 p位数组长度 m 和哈希函数个数 k 可以用两个公式算m -(n * ln(p)) / (ln(2)^2)k (m / n) * ln(2)我算一个实际数字。一个 jar 包通常有几千个 class 条目按 n2000、p1% 算m 大约是 20054 bit约 2.5KBk 约为 7。也就是说一个 jar 的布隆过滤器只需要 2.5KB。如果 classpath 上有 300 个 jar全部索引加起来不到 1MB如果用HashMap存全量类名到 jar 的映射同样信息量下内存消耗可能是几十 MB 起步而且构建 HashMap 的时间本身就比生成 BF 长很多。误判率 pn2000 时的 m哈希函数个数 k5%约 1.55KB41%约 2.5KB70.1%约 3.6KB10对 class 数量增长到 12 万的项目用 0.1% 误判率做全套索引内存大约在 10MB 以内运行时加载索引的时间远小于传统方式扫描所有 jar entry 的时间。这也是它能显著提速的第一个前提空间成本足够低。2.3 Java 里的最小实现理论说完先给一个可用的最小实现。演示用真实项目建议换 MurmurHash 或者 Google Guava 的BloomFilter哈希质量更好参数计算也更省心。import java.util.BitSet; public class SimpleBloomFilter { private final BitSet bits; private final int size; private final int[] salts {0x7f3a, 0x5c67, 0x4c2b, 0x8d1f, 0xd93a, 0x44c7, 0x12ab, 0x9e21, 0x3b4d, 0x6f10}; public SimpleBloomFilter(int bitSize) { this.size bitSize; this.bits new BitSet(bitSize); } private int hash(String value, int salt) { int h 0; for (int i 0; i value.length(); i) { h 31 * h value.charAt(i); } return (h ^ salt) 0x7fffffff; } public void add(String value) { for (int salt : salts) { bits.set(hash(value, salt) % size); } } public boolean maybeContains(String value) { for (int salt : salts) { int idx hash(value, salt) % size; if (!bits.get(idx)) { return false; } } return true; } public byte[] toByteArray() { return bits.toByteArray(); } public static SimpleBloomFilter fromByteArray(byte[] data, int bitSize) { SimpleBloomFilter bf new SimpleBloomFilter(bitSize); BitSet loaded BitSet.valueOf(data); bf.bits.or(loaded); return bf; } }需要注意这里salts数组模拟 k 个独立哈希函数实际工程中可以把字符串先算一个 64 位哈希再拆成多个子哈希避免多次遍历字符串。生产环境还可以把 bit 数组换成MappedByteBuffer用内存映射加载索引文件减少启动期拷贝。3. BLOOM 提速 jar 加载的核心设计3.1 让每个 jar 都带一个“门卫”落地思路很直接为 classpath 里每个 jar 单独建一个 BF索引里记录这个 jar 中全部 class/resource 条目的名称。运行时类加载器要查com/example/Service.class时先把这个资源路径喂给所有 BF结果为 false 的 jar 直接跳过完全不用打开结果为 true 的 jar 才放进候选列表逐个精确查找。这个流程避开了原有逻辑里最贵的“每次都要开 jar 尝试”。查询 BF 是纯内存位运算一次微秒级打开一个 jar 做 zip 查找是磁盘 IO一次可能几百微秒到毫秒级。两者有几个数量级的差距。假设查 100 个 jarBF 方式先做 100 次内存查询过滤到一两个候选再开一次文件总成本几乎就是一次文件打开的成本。3.2 普通 classpath 和 FatJar 分别怎么设计普通 classpath 应用在构建阶段用 Maven/Gradle 插件扫描 lib 目录生成一个bf-index.dat里面是 jar 名加 BF 序列化结果。自定义 ClassLoader 启动时把索引加载进内存loadClass先走 BF 过滤。Spring Boot 的 FatJar本质一样只是要处理嵌套 jar。构建时扫描BOOT-INF/lib下的每个 jar把各自的 class 条目生成 BF运行时在自定义 Launcher 或自定义 URLStreamHandler 层维护这些 BF。类加载器向某个嵌套 jar 取 entry 前先问 BF 值不值得开。我建议把索引放在META-INF/bf-index.dat并随构建产物分发。这样部署环境拿到的是一个现成索引运行期不需要重新扫描 jar启动自然快。索引文件可以放在 fat jar 内部也可以放在 jar 同级的配置目录里取决于你希望它参与镜像分层缓存还是纯粹只读资源。3.3 复杂度对比和适用边界传统方式M 个 jar每个 jar 内部查找平均 O(logM)最坏情况要打开 M 次文件。BF 方式先做 M 次位测试再把少数候选 jar 打开精确查找。位测试常数极小所以整个动作的时间上限由“打开文件次数”转移到了“内存位运算次数”。对比项传统 URLClassLoaderBF 加速类加载查找一个类逐个打开 jar直到命中先过滤掉绝大多数 jar再打开候选最坏打开 jar 次数M 次1 到 误判命中数 次单次成本磁盘 IO 解压查找内存位测试 1 次精确查找内存成本无额外索引每个 jar 约 2.5KB~3.6KB适用范围也很明确jar 数量足够多时收益才明显。我个人的判断标准是 classpath 至少在百个 jar 以上低于这个规模BF 索引的构建和加载成本可能反而吃亏。还有一点要说明BF 优化的是“调度的成本”不是解压计算本身的成本所以如果你的瓶颈已经不在文件打开上这招就不对症。4. 实操落地从零写一套 BF 加速类加载方案4.1 整体结构方案拆成三个阶段构建期生成索引、运行期加载索引、校验和回退。下面按步骤给代码和配置。bf-tools构建期扫描 jar 并生成bf-index.datfast-classloader运行期自定义 ClassLoaderSpring Boot 集成在 main 前置初始化或者替换 Launcher4.2 构建期扫描 jar 并生成索引import java.io.*; import java.nio.file.*; import java.util.*; import java.util.jar.*; import java.util.zip.*; public class IndexBuilder { public static void main(String[] args) throws Exception { Path libDir Path.of(args[0]); Path output Path.of(args[1]); Listbyte[] indexes new ArrayList(); try (DirectoryStreamPath stream Files.newDirectoryStream(libDir, *.jar)) { for (Path jarPath : stream) { try (JarFile jar new JarFile(jarPath.toFile())) { int count countEntries(jar); double p 0.001; int m (int) (-count * Math.log(p) / (Math.pow(Math.log(2), 2))); m (m 7) / 8 * 8; // 对齐到字节 SimpleBloomFilter bf new SimpleBloomFilter(m); EnumerationJarEntry entries jar.entries(); while (entries.hasMoreElements()) { bf.add(entries.nextElement().getName()); } // 自定义序列化jarName bitSize byte[] ByteArrayOutputStream bos new ByteArrayOutputStream(); DataOutputStream dos new DataOutputStream(bos); dos.writeUTF(jarPath.getFileName().toString()); dos.writeInt(m); byte[] bits bf.toByteArray(); dos.writeInt(bits.length); dos.write(bits); indexes.add(bos.toByteArray()); } } } try (DataOutputStream dos new DataOutputStream(new BufferedOutputStream(Files.newOutputStream(output)))) { dos.writeInt(indexes.size()); for (byte[] data : indexes) { dos.write(data); } } } private static int countEntries(JarFile jar) { int count 0; EnumerationJarEntry entries jar.entries(); while (entries.hasMoreElements()) { entries.nextElement(); count; } return count; } }注意两点entry 名要原样存不要转类全限定名。ClassLoader 查找时用的 key 是com/example/Service.class这样的路径BF 里存的也是这个路径两边一致才不会出现假阴性。另外bitSize要按实际 count 计算并取整到字节避免序列化后 bit 错位。4.3 运行期自定义类加载器import java.io.*; import java.net.*; import java.nio.file.*; import java.util.*; import java.util.concurrent.*; import java.util.jar.*; public class BloomFilterClassLoader extends URLClassLoader { private final MapPath, SimpleBloomFilter filters new ConcurrentHashMap(); private final MapPath, JarFile jarCache new ConcurrentHashMap(); public BloomFilterClassLoader(URL[] urls, ClassLoader parent) { super(urls, parent); loadBloomIndex(); } Override protected Class? findClass(String name) throws ClassNotFoundException { String resourceName name.replace(., /) .class; ListPath candidates new ArrayList(); for (Map.EntryPath, SimpleBloomFilter entry : filters.entrySet()) { if (entry.getValue().maybeContains(resourceName)) { candidates.add(entry.getKey()); } } for (Path jarPath : candidates) { try { JarFile jar jarCache.computeIfAbsent(jarPath, p - { try { return new JarFile(p.toFile()); } catch (IOException e) { throw new UncheckedIOException(e); } }); JarEntry entry jar.getJarEntry(resourceName); if (entry ! null) { byte[] data jar.getInputStream(entry).readAllBytes(); return defineClass(name, data, 0, data.length); } } catch (Exception e) { // 继续下一个候选 } } // 兜底BF 有误判也可能因为构建期漏配必须走原生逻辑 return super.findClass(name); } private void loadBloomIndex() { // 从 META-INF/bf-index.dat 读取索引并填充 filters // 具体序列化格式与 IndexBuilder 对应 } }代码里保留了super.findClass(name)兜底这是底线。BF 允许假阳性不允许假阴性但工程上构建索引时可能漏掉某个 jar也可能索引文件和实际部署包不匹配所以回退机制能避免上线后偶发ClassNotFoundException。资源查找findResource也要同理处理。否则 Spring 扫描 classpath 资源时又走回原生逻辑启动优化会大打折扣。另外运行时尽量缓存JarFile不要每次命中都重新 open并发加载场景下文件句柄复用对性能影响很明显。4.4 Spring Boot 项目怎么接进来Spring Boot 场景最干净的方式是自定义 Launcher 替换默认JarLauncher在创建LaunchedURLClassLoader之前把 BF 索引读进来让自定义类加载器优先用它过滤嵌套 jar。如果你不想动 Launcher还有一个性价比更高的折中方案用 BF 过滤 Spring 的ClassPathScanningCandidateComponentProvider扫描范围。Spring 启动时会对所有候选类做路径扫描跳过那些不含目标注解的 jar整体启动也能快不少改造点少、风险低。如果项目不是 Spring Boot只是普通 java -cp 启动直接把BloomFilterClassLoader放进启动入口把原本Launcher创建的类加载器替换成它就行。用 javaagent 方式也能做原理是拦截URLClassLoader.findClass的路径但维护成本稍高不如直接换启动器。5. 实测效果与踩坑记录5.1 一组有代表性的数据指标优化前优化后全量启动时间含 Spring 初始化6.8s2.2s类加载阶段耗时3.5s0.7s打开 jar 文件次数JFR 采样12 万不到 2000类路径扫描阶段1.6s0.4s配合 BF 过滤这个数据来自一次 300 多个 jar、约 12 万个 class 的改造记录机器是普通 SSD 加 JDK17。换到机械盘收益会更大如果依赖本身就少、jar 包不到 50 个收益就不明显甚至索引加载时间会抵消收益。启动慢也不一定都是类加载问题先看火焰图再动手。我个人的判断标准很简单打开 jar 次数明显高、CPU 等待 IO 比例高、启动时间与 jar 包数量正相关时这个方案才值得上。5.2 常见问题与避坑清单误判率设置过高导致收益下降。我见过有人图省内存把误判率设成 5%结果候选 jar 经常有两三个收益明显打折。0.1% 也就多几十 KB别省这笔内存。类名 key 格式不一致。包名点号、路径斜杠、内部类的$符号、资源文件的前缀这些细节最容易让 BF 索引失效。构建期和运行期必须用同一套转换规则建议抽成一个公共方法。JDK 9 模块系统限制。JDK9 之后内置URLClassLoader的findClass行为有变化自定义 ClassLoader 要遵守模块边界不要试图直接替换 AppClassLoader。用-cp模式加自定义 loadClass 入口风险最小。索引与 jar 版本失配。构建插件要在索引文件头写入 sha256 或构建时间运行期校验不过就回退原生加载并告警否则上线后偶尔出现ClassNotFoundException排查会非常痛苦。布隆过滤器不能删除元素。如果项目有动态卸载类、热插件加载一个 BF 从头建到尾没法撤位。要么用分层 BF要么定期重建索引。不在启动瓶颈时别硬优化。耗时大头可能在 Bean 初始化或数据库连接用 BF 没有用。先跑一次 JFR确认热点在类加载和 jar 打开再动手。FatJar 与解压目录的选择。如果你能接受把所有依赖解压成 classes 目录并加入 classpath类加载天然更快。但依赖版本冲突管理会很痛苦。BF 方案能保留 jar 独立性同时把查找成本压到接近目录级别。5.3 如果不想从零实现自己写 BF ClassLoader 大约几百行想更快验证先用 Guava 的BloomFilter做原型确认收益后再把 bit 数组改成MappedByteBuffer或自定义序列化。社区也有开源启动加速器实现原理基本一致直接拿来用要确认它匹配你的 JDK 和 Spring Boot 版本。还有一个建议配合 JDK 本身的 CDSClass Data Sharing一起用。CDS 能缓存核心 JDK 类与 Spring 框架类的归档BF 索引负责第三方 jar 的位置定位两者作用面不同可以叠加。Spring Boot 3.x 的 CDS/AOT 能力已经比较成熟冷启动优化讲究组合拳不要只押一个技术点。做完这轮改造我印象最深的一点是布隆过滤器真正起作用的不是它“存下了什么”而是它用微小的 bit 数“确认了不在哪些地方”。类加载恰恰非常依赖这种高置信度的否定判断。它把启动阶段大量磁盘打开操作转成内存位测试启动时间从让人焦躁的十几秒变成拿杯水的功夫。后续如果继续扩展我会把这个 BF 索引放进构建缓存和镜像分层里让每次 CI 构建出的应用都直接带着索引配合 CDS 把它做成一套默认的冷启动加速基建。如果你也在被大量 jar 包的启动时间折磨不妨先取一批 jar 做个小实验用数据决定要不要在项目里落地这套方案。