大家在平时开发的过程中，经常会在Aone上部署自己的应用进行功能验证，可能都会遇到应用在Aone上部署非常慢性，其中花在打包上的时间就差不多有7-8分钟，非常影响开发效率，下图就是一个非常典型应用在aone上部署构建一次所花的时间：
![image.png]( "image.png")
长期这么下去，肯定会是有问题，主要有如下两个方面的问题：
1. 应用打出的War包会越来越大，部署一次所花的时间会越来越长；
2. 新的需求，会不断升级已经的jar包和引入新的jar包，每个jar包会随着时间的推移，各个版本依赖深浅不断的变化，导致同一个应用中同一个jar包真正依赖的jar的版本不同，有时会出现莫期妙的问题，例如
![image.png]( "image.png")
图中honolulu-common，现在看是依赖的最终版本是1.0.2，也许明天又有一个新人依赖进来，间接依赖了honolulu-common，如果版本高，最终依赖的版本就高，这是只maven依赖深度不同而已，平时我们接触到的其它应用提供的二方包，比这种情况要复杂得多，这恐怕才是导致我们的业务系统依赖的jar包越来越多，间接依赖的jar包版本不断变化，应用打出的war包越来越慢的根本原因，下面就来分享一下自己在这段时间对应用的jar包进行排除来提升应用打包速度所做的工作：
1.安装idea插件Maven Helper
如果发现自己的idea没有安装，就安装Maven Helper
![image.png]( "image.png")
安装Maven Helper插件以后，重启Idea, 随便点击项目中任意一个模块的pom.xml，如果左下角出现Dependency Analyzer，说明插件安装成功,如下图所示：
![image.png]( "image.png")
点击Dependency Analyzer， 如下图所示：
![image.png]( "image.png")
输入你想要排除的jar包，点击右键，出现Exclude，再点击Exclude即可排除该包的的依赖
2. 二方包&客户端jar包排除：
二方包&客户端jar排除相对比较容易，基本的原则是： 不影响二方包打包发布成功的jar都可以排除掉，拿lafite这个应用的二方包来说，除了latour-client, commons-lang3和slf4j-api 这三个jar以外，其它的二方包都用不上，都可以排除，排除以后，发现lafite-client打包的速度超超快, 如下图：
排包后：
![image.png]( "image.png")
打包前：
![image.png]( "image.png")
对比打包前和打包后，我们发现，排包后，打包的速度差不多提高了近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"
如下图所示：
![image.png]( "image.png")
这样每个类在加载的时候，详细的加载信息会在tomcat_stdout.log这个文件中打出, 部分信息如下图所示：
![image.png]( "image.png")
图中包含每个类加载，以及这个类来自那个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中如下图所示：
![image.png]( "image.png")
这些无用的jar基本上都可以排除掉，排除掉以后，打出的war包会小很多：
下面是排包前后，打出的war包大小对比：
排包前：
![image.png]( "image.png")
排包后：
![image.png]( "image.png")
对比排包优化前后发现，war包的大小由340M左右减少到160M左右，整整减少一半以上，当然这160M中还包含了近200个被检测无用的jar包，如果把这200个左右的jar包也排掉的话， 估计最终打出的war包会更小；
5. 建议：
1.
提前把这个定时任务在线上加了，只有程序运行的时间越长，才能够更加确定那些jar包是无用的，这个时间一般要2-3周的时间，如果中间有一个大促会是再好不过了，不明确的地方，找熟悉的人进行功能回规，实在没有人熟悉的功能，就只能通过线上beta了，当然风险一定要可控，一般情况下，是发布了一个新版本，一定要及时拉一个新分支，随时应对jar包排错的风险
2.
优先排掉比较的无用而且比较大jar包，这样排包的效果会更明显；
3.
同一个jar包的不同版本，尽量排掉依赖更深的依赖，在不好处理的情况下，加直接依赖，然后再把间接依赖全部去掉，减少了间接依赖，有利于打包速度的提高，同时还可以防止jar间接升级导致的不可控的问题;
4 优化效果：
排包优化之前：
![image.png]( "image.png")
排包优化之后：
![image.png]( "image.png")
排包优化前后，打包构建时间整整减少一半以上，打包构建速度整理提高了100%以上
文章中有不足或没有写清楚的地方，欢迎大家指出纠正，一起进步成长
后面会介绍如何监控一个应用中启动比较慢性的Bean，以及在公司内部，如何优化这些启动比较慢性的Bean
