java并发[一]探索获取合理的并发数

 背景介绍：

         最近技术调研，需要一次性解析大量的velocity模板，velocity解析做了大概的优化配置。其中，性能瓶颈主要涉及到批量Velocity模板解析和批量文件写入。为了满足效率要求，使用java.util.concurrent.Executors [JDK1.5 引入的线程池管理]管理并发，写了个工具类，采用固定数目的线程池，如下

public class ExecutorTaskHelper {      private ExecutorService executor;         private staticExecutorTaskHelper instance = new ExecutorTaskHelper();         private ExecutorTaskHelper() {         executor = Executors.newFixedThreadPool(AppConfig.getInstance().getIntValue("concurrence.threads.num", 10));     } /**      * 添加给定的任务，当所有任务完成或超时期满时（无论哪个首先发生），返回保持任务状态和结果的 Future 列表。      * @param tasks 任务列表      * @param timeout 最长等待时间（单位：秒）      * @return表示任务的 Future 列表，列表顺序与给定任务列表的迭代器所生成的顺序相同。如果操作未超时，则已完成所有任务。如果确实超时了，则某些任务尚未完成。      * @throws InterruptedException 如果等待时发生中断，在这种情况下取消尚未完成的任务      */public static <T>List<Future<T>> addTask(Collection<? extends Callable<T>> tasks, int timeout) throws InterruptedException {         if(CollectionUtils.isNotEmpty(tasks)) {              return instance.executor.invokeAll(tasks, timeout, TimeUnit.SECONDS);         }         return null;     }}

 

1.      并发批量解析Velocity模板

其中，Velocity文本模板的行数达到3000多行，需要解析的数量一次性达到1000个以上。暂时不考虑velocity的解析优化。先从并发数测试触发，看看如何控制并发数。首先，将大概的解析方式罗列如下：

/**       * 并发解析Velocity文件       * @param factor 并发乘数因子       * @param templateContent 模板String       * @param contextMap 模板解析上下文map       * @throws InterruptedException       * @throws ExecutionException       * @throws IOException       */      public static long concurrencyParseContent(final float factor, final String templateContent, final List<Map<String, Object>>contextMaps) throws InterruptedException, ExecutionException,IOException {           LoggerUtil.logInfoEnabled(LOGGER, "The concurrent parsing start {}", new Date());           long start = System.currentTimeMillis();           //FIXME这个路径可能需要移到外部           final String filePath = AppConfig.getInstance().get("apm.template.content.store.path", "F:/temp");                     int poolNum = AppConfig.getInstance().getIntValue("concurrence.threads.num", 10);           int concurrencyNum = (int) (poolNum * factor);           List<Callable<Map<String,String>>> tasks = newArrayList<Callable<Map<String, String>>>(concurrencyNum);           //final Map<String, String>fileContentMap = new HashMap<String, String>(concurrencyOrgNum);           int index = 1;                     for (index = 1; index < contextMaps.size();index ++) {                 final Map<String, Object> contextMap =contextMaps.get(index);                 tasks.add( //使用匿名内部类                      new Callable<Map<String, String>>(){ //必须是一个接口或者类                                  public Map<String, String> call() throws Exception {                                       Stringresult = VelocityServiceUtil.mergeContentIntoString(templateContent,contextMap);                                       return MapUtil.newHashMap(filePath + "/filename" + IdUtils.uuid() + ".sh", result);                            }                      }                 );                 if (index % concurrencyNum == 0) {                      executeTasks(tasks);                      //重新填充任务                      tasks.clear();                 }                 /*if (index % concurrencyOrgNum == 0) {                      executeWriteFiles(fileContentMap);                      fileContentMap.clear();                 }*/ //不需要对存储做太多优化，可以降低内存使用率           }                     //最后一波处理任务           if (CollectionUtil.isNotEmpty(tasks)) {                 //executeWriteFiles(fileContentMap);                 executeTasks(tasks);           }           LoggerUtil.logInfoEnabled(LOGGER, "The concurrent parsing finish {}", new Date());           long useTime = System.currentTimeMillis()- start;           LoggerUtil.logInfoEnabled(LOGGER, "The use time {} ms", useTime);           return useTime;      }

如上，我们需要探讨的主要有三个参数，1. 解析数量，即contextMaps.size()，2. factor，这个是一个乘数因子，主要是为了方便能够在web应用中反复测试并发数，而不需要反复重启web工程，3. 线程池开启的固定线程数目poolNum。为了能找到性能优化的点，我采用物理中常见的控制变量法。

为了能够方便反复测试，写了个action，如下：

/** * @author linjx * @date 2014-8-21 * @version 1.0.0 */@ParentPackage("wsportal-default")public class TestConcurrentParseTemplateAction {           private float factor;      private int testNum;      private String message;       @Action(value = "/test/concurrent-parse",                 results= {@Result(name=BaseAction.SUCCESS, type="json")})      public String testParseTemplate() {           String template = null;           try {                 template = FileUtils.readFile("F:/velocity/msconf.vm");           } catch (IOException e) {                 e.printStackTrace();           }           ServerTemplateBo server = new ServerTemplateBo();           server.setIp("192.168.21.213");           server.setName("hello");           SoftwareTemplateBo software = new SoftwareTemplateBo();           software.setCacheType("4");           software.setConf("conf list");           software.setHasChildren(false);           software.setSquidId(1000000L);           software.setVersion("v1.0.0");                     Map<String, Object> contentMap= new HashMap<String, Object>(2);           contentMap.put("server", server);           contentMap.put("software", software);                     List<Map<String, Object>>contextMaps = new ArrayList<Map<String,Object>>(testNum);           for (int i = 1; i <= testNum; i ++) {                 contextMaps.add(contentMap);           }                     try {                 long useTime = VelocityConcurrencyUtil.concurrencyParseContent(factor, template, contextMaps);                 message = "总解析模板数: " + testNum + " "                            + "线程池线程数: " + poolThreadNum                            + "解析并发数: " + (factor * poolThreadNum) + "  "                            + "The use time " + useTime + " ms";           } catch (InterruptedException | ExecutionExceptione) {                 e.printStackTrace();           } catch (IOException e) {                 e.printStackTrace();           }                     return BaseAction.SUCCESS;      }           public String getMessage() {           return this.message;      }       public void setFactor(float factor) {           this.factor = factor;      }           public void setTestNum(int testNum) {           this.testNum = testNum;      }     }

我们只是使用了同一组数据，但是衍生出足够多的解析测试。

  

①  首先，测试一下解析的耗时和解析的数据量的关系

直觉上告诉我们，待解析的数目越多，耗时肯定也越多，而且应该是线性关系。我们做个测试，其中poopNum=10：

1.{"message":"总解析数: 100  并发因子: 1.0  The use time 1941 ms"}2.{"message":"总解析数: 1000  并发因子: 1.0  The use time 19700 ms"}3.{"message":"总解析数: 10000  并发因子: 1.0  The use time 192719 ms"}

结果显示，我们的判断是正确的。好的，那接下来就将contextMaps.size()值固定为500，这样做是为了避免CPU时间片轮转对测试造成波动，也可以避免数据量太大，导致测试等待太久，毕竟时间还是很宝贵的。

 

②变动factor并发因子，改变并发数（即一次性交给Executor的任务数）

一开始，我们开辟固定线程池，池内线程数固定为10个，然后不断修改factor，测试耗时如下

1. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 1.0  The use time 8285 ms"}2. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 2.0  The use time 6088 ms"}3. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 3.0  The use time 7252 ms"}4. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 4.0  The use time 8583 ms"}5. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 5.0  The use time 9762 ms"}6. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 8.0  The use time 10244 ms"}7. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 10.0  The use time 10533 ms"}8. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 20.0  The use time 10613 ms"}9. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 200.0  The use time 8728 ms"}10. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 500.0  The use time 8943 ms"}

通过上述数据，我们可以发现，任务的并发执行数并非越大越好，也不是越小越好，我反复测试发现，并发数为2是效率最高的。这是为什么呢？我仔细查看了，我的CPU是Intel i3，具体参数如下

核心类型

Arrandale

核心数量

双核心

热设计功耗(TDP)

35W

制作工艺

32 纳米

晶体管数目

3.82亿

核心面积

81平方毫米

封装模式

rPGA 37.5×37.5mm, BGA 34×28mm

我一直以为i3已经是四核了，可是不是，就双核而已；刚好和我们测试的结果是一致的。这样就不难解释了，虽然我们使用Executors开辟了10个固定的线程，如果我们一次性加载比较多的任务，根据操作系统的执行方式，使用Intel i3肯定是无法一次性就执行这么多任务，最多只能双核一起跑，即真正的同时执行两个线程（感觉，最终面向对象的执行还是很难逃脱面向过程的）。如果任务数大于实际真正的并发数，那在某个任务没有结束时，该任务会被挂起，等待下一个时间片轮转到它。这样，从某种程度上讲，CPU等于同时要处理多个任务，可是就只有两颗心，唯一能做的，就是分神，一边一边咯。自然，虽然CPU拥有很快的计算速度，但是还是会一定程度降低运行效率。除非CPU只做解析Velocity这件事，这样时间的耗散就理论上一致了——可惜，这是不可能的。

总结到这里，不禁联想到最近看的MapReduce。单机的计算能力终究是有限的，就像一个工人不可能单独一日完成一车间的任务，不管是横向的重复性任务还是纵向的流水线任务。MapReduce就像是集结一个车间的工人，分布式的使用了计算机集群。从这个优秀的框架我们可以看到车间流水线的影子。Map workers和Reduce workers分别负责分布式运算的流水任务，Reduce workers在Map workers完成第一轮的流水线任务之后就可以陆陆续续地开始自己的任务（如果有一节点既负责Map又负责Reduce任务，那还是需要串行执行的）。相同身份的workers是横向分布的，他们处理相同的任务，是单兵能力的有效扩展。备注：我对MapReduce算法解刨层面的理解是，对应数学上的微积分，一个先离散再聚合的过程，key对应的是微分参数。具体的理解，希望回头有机会实战后能给个有意义的讲解。至此打住，跑题太远。

回到正题，既然我们只能够真正同时执行两个线程，那线程池是不是也没有必要开辟那么大。毕竟我这里处理的方式是，执行完成一个任务集合后，在继续执行下一个任务集合，或者加入一堆的任务，由Executor自己分配。所以，如果这样，是不是直接把线程池开辟为2个就会提升效率呢？试试看（为了方便测试，poolNum也交由前端输入，具体代码小修改不做展示）：

1．{"message":"总解析模板数: 500  线程池线程数: 1  解析并发数: 1.0  The use time 12461 ms"}2. {"message":"总解析模板数: 500  线程池线程数: 2  解析并发数: 2.0  The use time 8717 ms"}3. {"message":"总解析模板数: 500  线程池线程数: 4  解析并发数: 4.0  The use time 11437 ms"}4. {"message":"总解析模板数: 500  线程池线程数: 10  解析并发数: 10.0  The use time 10623 ms"}5. {"message":"总解析模板数: 500  线程池线程数: 100  解析并发数: 100.0  The use time 10233 ms"}

(这测试过程中，我发现，由于本机有时候某些后台程序释放了资源，计算能力会提升，所以有时候计算能力会提升，所以，数据比对只在一个时间段内做比对，不跨时段)

上述，我们不过内存损耗的开辟比较大的线程池，结果如预计的那样，并没有提高解析速度。就此，我们可以认为，单纯的提交解析效率，合理的并发数应该是CPU可真正同时执行的线程数。