要说这个“正在初始化”，真是我这些年遇到的“钉子户”问题之一。那种看着程序启动画面，或者页面一直转圈，心里那叫一个憋屈。尤其是赶上急事儿的时候，真是能把人急得火冒三丈。
我记得有一次，我们团队接了个大项目，是给一个全国性的连锁企业做一套门店管理系统。整个系统特别庞大，模块贼多，数据结构也复杂。我们吭哧吭哧搞了一年多，总算把核心功能都跑通了。到了联调测试的时候，那叫一个惨烈。
系统一启动，一个大大的“正在初始化中…”就跳出来了，然后就没有然后了。一开始以为是网络问题，查了半天不是。又以为是数据库连接慢，各种优化也做了，结果也没啥用。每次开机，等待时间至少得两三分钟，我当时就傻眼了。客户那边等着看效果，我这每次演示都得提前十分钟把程序开起来，生怕当场卡住。那种压力，真是感觉头顶悬着把刀。
当时我就觉得不对劲，不可能这么慢。我开始挨个排查，代码一行一行地看，就像个老中医把脉一样。先是怀疑是不是加载了太多不必要的东西，把那些平时不用的模块，或者一些只在特定场景才用的功能，都一股脑儿地在程序启动的时候就全部加载进来了。那会儿代码写得比较糙，也没想那么多，觉得一股脑加载进来以后用着方便，没想到挖了个坑。
第一个发现：别什么都一股脑儿地往里塞
我当时琢磨着，是不是可以先把必需的核心功能跑起来，那些平时不急着用的，或者要点到具体菜单才需要的东西，就让它需要的时候再加载？就像咱们去超市，不可能把所有商品都堆在门口，得按区域分好类，顾客想买什么再去什么区。
我当时就花了几天时间，把那些非核心的模块，尤其是涉及到大量数据初始化或者复杂计算的模块，都改成了“懒加载”。也就是我把它们的初始化逻辑都包装了一下，只有当系统真的调用到那些模块里的功能时，才去触发它们的初始化。这一改，启动速度立马就有了改善，从三分钟降到了差不多一分钟。当时心里那个高兴劲儿，像孩子考试得了满分。
可一分钟对于客户来说还是太慢了，他们想要的是那种点一下就能用的感觉。我不能满足于此，还得继续找办法。
第二个发现：以前算过的，就别再算了
在接着排查的过程中，我发现了一些很有意思的现象。有些数据，尤其是那些系统配置，或者一些很少变动的、需要计算很久才能得出来的数据，每次启动的时候都会重新加载、重新解析、重新计算一遍。比如，我们有一个复杂的权限树结构，每次启动系统都要从数据库里读出来，然后解析成内存对象。
我当时就拍脑袋想：这些东西明明每次都一样，为啥不存起来？就像我们吃盒饭，没必要每次都从头炒菜？头一天炒好了，装盒，第二天热一下就能吃。于是我就尝试引入了“缓存”这个概念，那时候也不是什么专业的缓存框架，就是自己写了个简单的机制。
我把那些每次启动都重复加载、重复计算、重复解析的配置和数据，在系统第一次成功运行后，就把它序列化一下，存到本地文件里。下次启动的时候，先检查一下有没有这个文件，如果有，就直接读取这个文件，把之前存好的数据加载进来，省去了大量的计算和数据库查询时间。如果文件不存在或者数据有变动（比如版本更新），那再重新计算和生成一次。
这一招，效果是立竿见影的！启动时间又从一分钟锐减到了三十秒左右。客户再来看的时候，明显感觉系统“活”过来了。他们还是觉得不够快，但是至少能接受了。我也算是松了口气，至少没有砸锅。
第三个发现：能同时干的活，就别排队了
三十秒虽然能接受，但作为搞技术的，总想追求极致。我在想，还有没有地方可以优化？我仔细分析了一下，系统初始化的时候，虽然有些模块我做了懒加载，有些数据做了缓存，但还有很多独立的初始化任务，它们之间是互不依赖的，但当时的代码逻辑就是让他们一个个排着队执行，前一个不完，后一个就不开始。
我当时就想，这不就是“单线程”思维吗？就好比你炒菜，洗菜、切菜、烧水、热锅，这些事情有些是可以同时进行的，没必要等一个做完再开始下一个。我于是开始把那些相互独立的初始化任务，都拆分开来，让它们同时启动、并行执行。我利用了当时我们开发框架自带的异步任务机制，把那些独立的初始化方法都扔到不同的“线程”里，让它们各自跑各自的。
这里面有个坑，就是要注意任务之间的依赖关系，有些任务确实是需要等别的任务完成了才能开始的，比如权限系统初始化完了，才能加载用户相关的偏好设置。我当时就花了不少时间去梳理这些依赖关系，确保那些可以并行的任务都能并行起来，而有依赖的则乖乖排队。
这第三个技巧，可以说是个“组合拳”，结合前两个，直接把系统的启动时间又砍掉了一大截，最终稳定在了十秒以内！当我再给客户演示的时候，他们甚至都没注意到“正在初始化”这几个字，系统就已经跑起来了。那种成就感，真是没法形容。
从那以后，我再写代码，启动速度就是我关注的重点之一了。这些年，我发现不管什么项目，只要是慢得让人崩溃的初始化，基本上都是这三个问题：要么是加载了太多不需要的东西，要么是重复计算了以前算过的，要么就是能并行的任务非得排队。掌握了这三个小技巧，基本上就能解决大部分问题。