如何让Java应用在Aone上打包速度提高100%以上
大家在平时开发的过程中，经常会在Aone上部署自己的应用进行功能验证，可能都会遇到应用在Aone上部署非常慢性，其中花在打包上的时间就差不多有7-8分钟，非常影响开发效率，下图就是一个非常典型应用在aone上部署构建一次所花的时间：长期这么下去，肯定会是有问题，主要有如下两个方面的问题： 1. 应用打出的War包会越来越大，部署一次所花的时间会越来越长； 2. 新的需求，会不断升级已经的jar包和引入新的jar包，每个jar包会随着时间的推移，各个版本依赖深浅不断的变化，导致同一个应用中同一个jar包真正依赖的jar的版本不同，有时会出现莫期妙的问题，例如 图中honolulu-common，现在看是依赖的最终版本是1.0.2，也许明天又有一个新人依赖进来，间接依赖了honolulu-common，如果版本高，最终依赖的版本就高，这是只maven依赖深度不同而已，平时我们接触到的其它应用提供的二方包，比这种情况要复杂得多，这恐怕才是导致我们的业务系统依赖的jar包越来越多，间接依赖的jar包版本不断变化，应用打出的war包越来越慢的根本原因，下面就来分享一下自己在这段时间对应用的jar包进行排除来提升应用打包速度所做的工作： 1.安装idea插件Maven Helper 如果发现自己的idea没有安装，就安装Maven Helper安装Maven Helper插件以后，重启Idea, 随便点击项目中任意一个模块的pom.xml，如果左下角出现Dependency Analyzer，说明插件安装成功,如下图所示：点击Dependency Analyzer， 如下图所示：输入你想要排除的jar包，点击右键，出现Exclude，再点击Exclude即可排除该包的的依赖 2. 二方包&客户端jar包排除： 二方包&客户端jar排除相对比较容易，基本的原则是： 不影响二方包打包发布成功的jar都可以排除掉，拿lafite这个应用的二方包来说，除了latour-client, commons-lang3和slf4j-api 这三个jar以外，其它的二方包都用不上，都可以排除，排除以后，发现lafite-client打包的速度超超快, 如下图：排包后：打包前：对比打包前和打包后，我们发现，排包后，打包的速度差不多提高了近3倍左右，提速还是非常明显 经验： 1. 二方包依赖的jar 包越小越好，去掉一切无用的Jar包，判断的标就是打出的二方包不出错，即可，当然这么做会有风险，但一般的二方包都不是特别复杂，在打包的时候，基本上都能判断出来 2. 最好用maven3.0+以上的版本打二方包，不到万不得已，不要用maven2.2.1版本打二方，这会坑了其它依赖你二方包的开发同学，导致其它用依赖用maven2.2.1版本打出的二方包无法做Maven升级 3. 应用本身二方包排除： 应用本身的二方包排除要稍微复杂些，首先要确认那些jar包对应用来确实无用，这个确认的过程比较长，可以用一个定时任务来确认，方法如下： 1. 在应用的各个环境的脚本文件setenv.sh中，找到下面这一行： CATALINA_OPTS="{CATALINA_OPTS} -Dhsf.publish.delayed=false"， 然后在这一行加上下面这一行： CATALINA_OPTS="{CATALINA_OPTS} -XX:+TraceClassLoading"如下图所示：这样每个类在加载的时候，详细的加载信息会在tomcat_stdout.log这个文件中打出, 部分信息如下图所示：图中包含每个类加载，以及这个类来自那个jar包，例如：org.apache.catalina.util.LifecycleBase 这个类被加载时，是来自catalina这个jar包，/opt/taobao/install/tomcat-7.0.59.3/lib/catalina.jar 2. 在应用中添加一个定时任务检测类： myju中的定时任务检测类是com.taobao.ju.my.performance.CheckNoUsedJarsJob， 代码如下： /** * 检查无用jar包 * desheng.tds */ public class CheckNoUsedJarsJob implements SimpleJobProcessor { private static Logger logger = LoggerFactory.getLogger(CheckNoUsedJarsJob.class); @Override public ProcessResult process(SimpleJobContext simpleJobContext) { try { File tomcatStdoutLog = new File("/home/admin/myju/logs/tomcat_stdout.log"); File jarDir = new File("/home/admin/myju/target/myju.war/WEB-INF/lib"); String[] fileNames = jarDir.list(); BufferedReader bufferedReader = new BufferedReader(new FileReader(tomcatStdoutLog)); String line = null; Set<String> sysJars = new HashSet<>(); Set<String> lines = new HashSet<>(); List<String> noUsedJars = new LinkedList<>(); while ( (line = bufferedReader.readLine()) != null ) { // System jar包 if (line.startsWith("[Loaded") && line.contains("from") && line.contains("taobao-hsf.sar") && line.contains("/opt/taobao/install")) { int index = line.lastIndexOf("]"); String sysJar = line.substring(0, index); index = sysJar.lastIndexOf(" "); sysJar = sysJar.substring(index+1); if (sysJar.endsWith("!/") && sysJar.length() > 2) { sysJar = sysJar.substring(0, sysJar.length() - 2); } index = sysJar.lastIndexOf("/"); sysJar = sysJar.substring(index+1); sysJars.add(sysJar); } if (line.startsWith("[Loaded") && line.contains("from") && !line.contains("taobao-hsf.sar") && !line.contains("/opt/taobao/install")) { int startIndex = line.lastIndexOf("/"); int endIndex = line.indexOf(".jar]"); if (startIndex >= 0 && endIndex>0 && endIndex + 4 <= line.length()) line = line.substring(startIndex+1, endIndex + 4); lines.add(line); } } for (String fileName : fileNames) { if (!lines.contains(fileName) && !sysJars.contains(fileName)) { noUsedJars.add(fileName); } } for (String fileName : noUsedJars) { File file = new File("/home/admin/myju/target/myju.war/WEB-INF/lib/" + fileName); String strLen = null; long len = file.length()>> 10; if (len > 1024) { strLen = (len * 1.0 /1024) + "MB" ; } else { strLen = len + "kB"; } logger.warn("fileName=:{}, size={}", fileName, strLen); } } catch (Exception e) { logger.warn("[CheckNoUsedJarsJob.process] error e={}", e); } return new ProcessResult(true); } } 代码的逻辑比较简单：在应用的war包WEB-INFO/lib目录中检查应用在启动和运行过程中不需要的jar包，一般依赖的war包的jar目录是"/home/admin/应用名/target/应用名.war/WEB-INF/lib/，例如myju应用的jar目录是："/home/admin/myju/target/myju.war/WEB-INF/lib/，当然有些jar包是来自JDK和Pandaro容器，这部分jar最好也不要排除 3.添加任务检测任务的日志 myju中日志配置如下： <appender name="CheckNoUsedJarsJob_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${ju.my.loggingRoot}/myju_check_no_used_jars.log</file> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} - %m%n</pattern> <charset>GBK</charset> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${ju.my.loggingRoot}/myju_check_no_used_jars.log.%d{yyyy-MM-dd}</fileNamePattern> <maxHistory>7</maxHistory> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>5000MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> </appender> <logger name="com.taobao.ju.my.performance.CheckNoUsedJarsJob" level="info" additivity="false"> <appender-ref ref="CheckNoUsedJarsJob_LOG"/> </logger> 即检查任务的日志每天打印在myju_check_no_used_jars.log文件中 4.启动任务，可以看到日志文件中有打印出的相关无用jar和大小 myju中如下图所示：这些无用的jar基本上都可以排除掉，排除掉以后，打出的war包会小很多：下面是排包前后，打出的war包大小对比：排包前：排包后：对比排包优化前后发现，war包的大小由340M左右减少到160M左右，整整减少一半以上，当然这160M中还包含了近200个被检测无用的jar包，如果把这200个左右的jar包也排掉的话， 估计最终打出的war包会更小； 5. 建议： 1. 提前把这个定时任务在线上加了，只有程序运行的时间越长，才能够更加确定那些jar包是无用的，这个时间一般要2-3周的时间，如果中间有一个大促会是再好不过了，不明确的地方，找熟悉的人进行功能回规，实在没有人熟悉的功能，就只能通过线上beta了，当然风险一定要可控，一般情况下，是发布了一个新版本，一定要及时拉一个新分支，随时应对jar包排错的风险 2. 优先排掉比较的无用而且比较大jar包，这样排包的效果会更明显； 3. 同一个jar包的不同版本，尽量排掉依赖更深的依赖，在不好处理的情况下，加直接依赖，然后再把间接依赖全部去掉，减少了间接依赖，有利于打包速度的提高，同时还可以防止jar间接升级导致的不可控的问题; 4 优化效果： 排包优化之前：排包优化之后：排包优化前后，打包构建时间整整减少一半以上，打包构建速度整理提高了100%以上 文章中有不足或没有写清楚的地方，欢迎大家指出纠正，一起进步成长 后面会介绍如何监控一个应用中启动比较慢性的Bean，以及在公司内部，如何优化这些启动比较慢性的Bean
