对纯for循环进行并行流和线程池优化简记

本文记录了在项目中优化纯for循环的过程,对比了原始for循环、并行流以及使用Spring线程池的异步执行三种方式的性能和结果稳定性。并行流表现出较好的优化效果,耗时712ms,而线程池异步执行耗时2627ms且结果集不稳定。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近在项目中需要根据角色拿对应任务(activiti 中的内容),再根据任务拿工单集(任务跟工单为多对一的关系,所以还需过滤掉重复的工单),获得最终结果集的耗时较大,所以考虑从多线程方向优化。

这些操作在一个for循环里涉及两处数据库查询IO,但IO的阻塞不严重,不属于IO密集型的多线程设计条件,所以采用线程池,优化的效果不是很好(对于IO阻塞系数较小的应用优化,多线程的使用,CPU在线程非阻塞的状态下切换上下文,消耗很大,同时还得加上创建线程的开销);采用concurrent包的Stream来进行并发流式的处理,优化效果还比较可观。

现针对三种不同的实现方式和执行效果通列如下:

原始for循环:

//同组测试数据,2038ms 结果集稳定

方法体:

List<WorkOrder> content = new ArrayList<WorkOrder>();
Map<String,Integer> widMap=new HashMap<String,Integer>();

for (String id : ids) {
List<Task> tasks = taskService.createTaskQuery()
.taskCandidateGroup(id).active().list();

//同组测试数据,2038ms 结果集稳定
for (Task task : tasks) {
ProcessInstance pi = runtimeService
.createProcessInstanceQuery()
.processInstanceId(task.getProcessInstanceId())
.singleResult();
String workOrderId = pi.getBusinessKey();
if(!widMap.containsKey(workOrderId)){
WorkOrder wo = workOrderService.findStartedWorkOrderAnd(
workOrderId, Constants.WORKORDER.CONFIGURED,
Constants.WORKORDER.INPROCESSED,
Constants.WORKORDER.UNFILLED);
if(wo!=null){
content.add(wo);
}
widMap.put(workOrderId, 1);
}
}

}

并行流:

//并行流,712ms 结果集稳定

方法体:

List<WorkOrder> cont

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值