问题一：为什么需要修改应用启动脚本？
为什么需要修改应用启动脚本？
参考回答：
因为应用现在不再是一个单独的fat.jar文件，而是一个目录结构。对于旧版本的pandora boot应用，原来可能包含解压操作的启动脚本现在可以不再需要解压步骤。而最新版本的pandora boot版本的应用由于已经兼容这种目录结构，所以不需要修改启动脚本。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/655813
问题二：autoconfig插件升级后，如何验证结果的正确性？
autoconfig插件升级后，如何验证结果的正确性？
参考回答：
通过对比优化前后的两个构建日志来验证结果的正确性。首先，搜索日志中的autoconfig产生的 "Generating META-INF" 数量是否一致，因为这代表了autoconfig的执行情况。其次，比较具体的配置了的jar包列表是否相同，以确保应用包含了相同的依赖和配置。如果这两点都相同，那么说明升级后的autoconfig插件在功能和结果上与原版本一致。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/655814
问题三：在优化后的日志中，为什么会出现"Runtime : ran out of parsers."的日志？
在优化后的日志中，为什么会出现"Runtime : ran out of parsers."的日志？
参考回答：
在优化后的日志中出现的"Runtime : ran out of parsers."日志是由velocity模板引擎报的错。由于现在是“多线程作配置”，同时进行的配置操作较多，导致velocity需要同时使用的parser数量增加。如果velocity的parser资源不足以满足多线程的需求，就会出现这样的日志提示。可能需要考虑增加velocity的parser资源或优化配置生成过程以减少对parser的并发需求。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/655815
问题四：新版本的autoconfig插件主要做了哪些优化？
新版本的autoconfig插件主要做了哪些优化？
参考回答：
新版本的autoconfig插件主要做了两个优化：一是使用线程池来并发执行config，提高了配置生成的效率；二是能并发执行的前提是autoconfig的目标是一个目录，而不是一个fat.jar文件。当目标是目录时，会先listFiles，再将fileList传给destFiles，从而支持了并发配置生成。 
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/655816
问题五：为何选择将autoconfig的目标设为目录而不是fat.jar文件？
为何选择将autoconfig的目标设为目录而不是fat.jar文件？
参考回答：
选择将autoconfig的目标设为目录而不是fat.jar文件，是因为当目标是目录时，可以方便地列出目录下的所有文件（listFiles），然后将这些文件列表（fileList）传递给目标文件（destFiles），进而支持多线程并发地执行配置生成，大大提高了构建效率。
关于本问题的更多回答可点击原文查看：
