1. 现状
集团整套电商系统已经运行好多年了，机器上运行的jar包，不会因为最近大环境不好而减少，只会逐年递增，而中台的几个核心应用，因为之前走的是“平台集成业务”的模式，像个黑洞一样，所有业务都在上面开发，膨胀得更加明显，比如热点应用A机器上运行的jar包就有上千个，jar包中包含的资源文件数量更是达到了上万级别，通过工具分析，发现热点应用A启动耗时中有180秒以上是花在classLoader上，占总耗时的1/3以上，其中占比大头的是findResource的耗时。
不论是loadClass还是getResource，最终都会调用到findResource，慢主要是慢在资源的检索上。现在spring框架几乎是每个Java必备的，各种annotation，各种扫包，虽然极大的方便开发者，但也给应用的启动带来不少的负担。目前集团有上万多个Java应用，classLoader如果可以进行优化，将带来非常非常可观的收益。
2. 解决方案
优化的方案可以简单的用一句话概括，就是给URLClassLoader的资源查找加索引。
3. 提速效果
目前中台核心应用都已升级，基本都有100秒以上的启动提速，占总耗时的20~35%，效果非常明显！
4. 原理
1) 原生URLClassLoader为什么会慢
Java的JIT（just in time）即时编译，想必大家都不陌生，JDK里不仅仅是类的装载过程按这个思想去设计的，类的查找过程也是一样的。通过研读URLClassPath的实现，你会发现以下几个特性：
• URLClassPath初始化的时候，所有的URL都没有open。
• findResources会比findResource更快的返回，因为实际并没有查找，而是在调用Enumeration的next()的时候才会去遍历查找，而findResource去找了第一个。
• URL是在遍历过程逐个open的，会转成Loader，放到loaders里（数组结构，决定了顺序）和lmap中（Map结构，防止重复加载）。
• 一个URL可以通过Class-Path引入新的URL（所以，理论上是可能存在新URL又引入新的URL，无限循环的场景）。
• 因为URL和Loader是会在遍历过程中动态新增，所以URLClassPath#getLoader（int index）里加了两把锁。
这些特性就是为了按需加载（懒加载），遍历的过程是O（N）的复杂度，按顺序从头到尾的遍历，而且遍历过程可能会伴随着URL的打开，和新URL的引入，所以，随着jar包数量的增多，每次loadClass或者findResources的耗时会线性增长，调用次数也会增长（加载的类也变多了），启动就慢下去了。慢的另一个次要原因是，getLoader（int index）加了两把锁。
2) JDK为什么不给URLClassLoader加索引
跟数据库查询一样，数量多了，加个索引，立杆见效，那为什么URLClassLoader里没加索引。其实，在JDK8里的URLClassPath代码里面，是可以看到索引的踪影的，通过加“-Dsun.cds.enableSharedLookupCache=true”来打开，但是，我换各种姿势尝试了数次，发现都没生效，lookupCacheEnabled始终是false，通过debug发现JDK启动的过程会把这个变量从System的properties里移除掉。另外，最近都在升JDK11，也看了一下它里面的实现，发现这块代码直接被删除的干干净净，不见踪影了。
通过仔细阅读URLClassPath的代码，我能想到JDK没支持索引的原因有以下3点：
原因一：跟按需加载相矛盾，且URL的加载有不确定性
建索引就得提前将所有URL打开并遍历一遍，这与原先的按需加载设计相矛盾。另外，URL的加载有2个不确定性：
• 一是可能是非本地文件，需要从网络上下载jar包，下载可能快，可能慢，也可能会失败。
• 二是URL的加载可能会引入新的URL，新的URL又可能会引入新的URL。
原因二：不是所有URL都支持遍历
URL的类型可以归为3种：
• 本地文件目录，如classes目录。
• 本地或者远程下载下来的jar包。
• 其他URL。
前2种是最基本最常见的，可以进行遍历的，而第3种是不一定支持遍历，默认只有一个get接口，传入确定性的name，返回有或者没有。
原因三：URL里的内容可能在运行时被修改
比如本地文件目录（classes目录）的URL，就可以在运行时往改目录下动态添加文件和类，URLClassLoader是能加载到的，而索引要支持动态更新，这个非常难。
3) FastURLClassLoader如何进行提速
首先必须承认，URLClassLoader需要支持所有场景都能建索引，这是有点不太现实的，所以，FastURLClassLoader设计之初只为满足绝大部分使用场景能够提速，我们设计了一个enable的开关，关闭则跟原生URLClassLoader是一样的。
另外，一个java进程里经常会存在非常多的URLClassLoader实例，不能将所有实例都开打fast模式，这也是没有直接在AliJDK里修改原生URLClassLoader的实现，而是新写了个类的原因。
FastURLClassLoader继承了URLClassLoader，核心是将URLClassPath的实现重写了，在初始化过程，会将所有的Loader进行初始化，并遍历一遍生成index索引，后续findResources的时候，不是从0开始，而是从index里获取需要遍历的Loader数组，这将原来的O（N）复杂度优化到了O（1），且查找过程是无锁的。
FastURLClassLoader会有以下特征：
特征一：初始化过程不是懒加载，会慢一些
索引是在构造函数里进行初始化的，如果url都是本地文件（目录或Jar包），这个过程不会暂用过多的时间，3000+的jar，建索引耗时在0.5秒以内，内部会根据jar包数量进行多线程并发建索引。这个耗时，懒加载方式只是将它打散了，实际并没有少，而且集团大部分应用都使用了spring框架，spring启动过程有各种扫包，第一次扫包，所有URL就都打开了。
特征二：目前只支持本地文件夹和Jar类型的URL
如果包含其他类型的URL，会直接抛异常。虽然如ftp协议的URL也是支持遍历的，但得针对性的去开发，而且ftp有网络开销，可能懒加载更适合，后续有需要再支持。
特征三：目前不支持通过META-INF/INDEX.LIST引入更多URL
当前正式版本支持通过Class-Path引入更多的URL，但还不支持通过META-INF/INDEX.LIST来引入，目前还没碰用到这个的场景，但可以支持。通过Class-Path引入更多的URL比较常见，比如idea启动，如果jar太多，会因为参数过长而无法启动，转而选择使用“JAR manifest”模式启动。
特征四：索引是初始化过程创建的，除了主动调用addURL时会更新，其他场景不会更新
比如在classes目录下，新增文件或者子目录，将不会更新到索引里。为此，FastURLClassLoader做了一个兜底保护，如果通过索引找不到，会降级逐一到本地目录类型的URL里找一遍（大部分场景下，目录类型的URL只有一个），Jar包类型的URL一般不会动态修改，所以没找。
5. 注意事项
1) 索引对内存的开销
索引的是jar包和它目录和根目录文件的关系，所以不是特别大，热点应用A有3000+个jar包，INDEX.LIST的大小是3.2M。
2) 同名类的仲裁
tomcat在没有INDEX.LIST的情况下，同名类使用哪个jar包中的，存在一定不确性，添加索引后，仲裁优先级是jar包名称按字母排序来的，保险起见，可以对启动后应用加载的类进行对比验证。
