网站建设合同是否交纳印花税,哪些平台可以发广告,网站建设建设公司有哪些,网站外包后呗百度降权大家好#xff0c;我是三叔#xff0c;很高兴这期又和大家见面了#xff0c;一个奋斗在互联网的打工人。 在并发编程中#xff0c;了解任务的性质对于选择合适的并发策略和资源分配至关重要。本篇博客将深入探讨 CPU 密集型和 IO 密集型任务的概念#xff0c;分析它们在并…大家好我是三叔很高兴这期又和大家见面了一个奋斗在互联网的打工人。 在并发编程中了解任务的性质对于选择合适的并发策略和资源分配至关重要。本篇博客将深入探讨 CPU 密集型和 IO 密集型任务的概念分析它们在并发环境下的特点并进行举例说明。 什么是CPU密集型 对于 CPU 密集型任务由于大部分时间都花费在计算操作上使用过多的线程反而可能会增加上下文切换开销导致性能下降。在这种情况下通常会使用较小的线程池以充分利用 CPU 核心。选择固定大小的线程池使线程数等于可用的 CPU 核心数或者根据实际情况调整线程池大小。同时还可以考虑使用更高效的算法和并行计算技术来优化计算过程以提高 CPU 密集型任务的性能。 示例 现在假设我们正在开发一个复杂的图像处理应用需要对大量图像进行处理和分析。这个任务是CPU密集型的因为大部分时间都花费在进行图像处理算法上。 在这种情况下我们不应该使用过多的线程因为过多的线程可能会导致上下文切换的开销增加反而影响性能。相反我们可以使用一个较小的线程池例如使用固定大小的线程池使线程数等于可用的CPU核心数。 获取CPU核心线程数的方法 // 用于获取当前计算机可用的处理器核心数CPU核心数。这个方法返回一个整数值表示系统中可用的处理器核心数量通常用于确定在并发编程中需要创建多少个线程来充分利用计算资源。 int cpuSize Runtime.getRuntime().availableProcessors();// 创建一个固定线程池 ExecutorService executor Executors.newFixedThreadPool(cpuSize);什么是IO密集型 对于IO密集型任务由于大部分时间都花费在等待IO操作如文件读写、网络通信、数据库查询等上传统上会使用较大的线程池甚至是无界线程池以便能够并发地处理多个IO操作。在等待IO的过程中CPU资源不会被充分利用因此可以通过增加线程数来提高并发性能。但是需要注意过多的线程也会导致上下文切换开销增加因此需要在性能和资源消耗之间进行权衡。 // 例如处理网络请求 ExecutorService executor Executors.newCachedThreadPool(); for (String url : urls) {executor.submit(() - {// 发起网络请求并处理响应}); }如何设置线程数比较好 多线程编程中一般线程的个数都大于 CPU 核心的个数而一个 CPU 核心在任意时刻只能被一个线程使用为了让这些线程都能得到有效执行CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用这个过程就属于一次上下文切换。概括来说就是当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态以便下次再切换回这个任务时可以再加载这个任务的状态。 上下文切换对系统来说意味着消耗大量的 CPU 时间如果我们设置的线程池数量太小的话如果同一时间有大量请求需要处理可能会导致大量的请求在任务队列中排队等待执行甚至会出现任务队列满了之后请求无法处理的情况或者大量任务堆积在任务队列导致 OOM。这样很明显是有问题的CPU 根本没有得到充分利用。如果我们设置线程数量太大大量线程可能会同时在争取 CPU 资源这样会导致大量的上下文切换从而增加线程的执行时间影响了整体执行效率。 CPU 密集型N 1 将线程数设置为 NCPU 核心数1。比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断或者其它原因导致的任务暂停而带来的影响。一旦任务暂停CPU 就会处于空闲状态而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。 IO密集型2N大部分开发过程中遇到的都是IO密集型 系统会用大部分的时间来处理 I/O 交互而线程在处理 I/O 的时间段内不会占用 CPU 来处理这时就可以将 CPU 交出给其它线程使用。 案例分析接下来这部分来自转载非原创《美图技术团队》阅读后深有体会 原博客地址线程池在业务中的实践 https://tech.meituan.com/2020/04/02/java-pooling-pratice-in-meituan.html 3.1 业务背景 在当今的互联网业界为了最大程度利用CPU的多核性能并行运算的能力是不可或缺的。通过线程池管理线程获取并发性是一个非常基础的操作让我们来看两个典型的使用线程池获取并发性的场景。 场景1快速响应用户请求 描述用户发起的实时请求服务追求响应时间。比如说用户要查看一个商品的信息那么我们需要将商品维度的一系列信息如商品的价格、优惠、库存、图片等等聚合起来展示给用户。 分析从用户体验角度看这个结果响应的越快越好如果一个页面半天都刷不出用户可能就放弃查看这个商品了。而面向用户的功能聚合通常非常复杂伴随着调用与调用之间的级联、多级级联等情况业务开发同学往往会选择使用线程池这种简单的方式将调用封装成任务并行的执行缩短总体响应时间。另外使用线程池也是有考量的这种场景最重要的就是获取最大的响应速度去满足用户所以应该不设置队列去缓冲并发任务调高corePoolSize和maxPoolSize去尽可能创造多的线程快速执行任务。 场景2快速处理批量任务 描述离线的大量计算任务需要快速执行。比如说统计某个报表需要计算出全国各个门店中有哪些商品有某种属性用于后续营销策略的分析那么我们需要查询全国所有门店中的所有商品并且记录具有某属性的商品然后快速生成报表。 分析这种场景需要执行大量的任务我们也会希望任务执行的越快越好。这种情况下也应该使用多线程策略并行计算。但与响应速度优先的场景区别在于这类场景任务量巨大并不需要瞬时的完成而是关注如何使用有限的资源尽可能在单位时间内处理更多的任务也就是吞吐量优先的问题。所以应该设置队列去缓冲并发任务调整合适的corePoolSize去设置处理任务的线程数。在这里设置的线程数过多可能还会引发线程上下文切换频繁的问题也会降低处理任务的速度降低吞吐量。 3.2 实际问题及方案思考 线程池使用面临的核心的问题在于线程池的参数并不好配置。一方面线程池的运行机制不是很好理解配置合理需要强依赖开发人员的个人经验和知识另一方面线程池执行的情况和任务类型相关性较大IO密集型和CPU密集型的任务运行起来的情况差异非常大这导致业界并没有一些成熟的经验策略帮助开发人员参考。 关于线程池配置不合理引发的故障公司内部有较多记录下面举一些例子 Case12018年XX页面展示接口大量调用降级 事故描述XX页面展示接口产生大量调用降级数量级在几十到上百。 事故原因该服务展示接口内部逻辑使用线程池做并行计算由于没有预估好调用的流量导致最大核心数设置偏小大量抛出RejectedExecutionException触发接口降级条件示意图如下 Case22018年XX业务服务不可用S2级故障 事故描述XX业务提供的服务执行时间过长作为上游服务整体超时大量下游服务调用失败。 事故原因该服务处理请求内部逻辑使用线程池做资源隔离由于队列设置过长最大线程数设置失效导致请求数量增加时大量任务堆积在队列中任务执行时间过长最终导致下游服务的大量调用超时失败。示意图如下 面对业务中使用线程池遇到的实际问题我们曾回到支持并发性问题本身来思考有没有取代线程池的方案也曾尝试着去追求线程池参数设置的合理性但面对业界方案具体落地的复杂性、可维护性以及真实运行环境的不确定性我们在前两个方向上可谓“举步维艰”。最终我们回到线程池参数动态化方向上探索得出一个且可以解决业务问题的方案虽然本质上还是没有逃离使用线程池的范畴但是在成本和收益之间算是取得了一个很好的平衡。成本在于实现动态化以及监控成本不高收益在于在不颠覆原有线程池使用方式的基础之上从降低线程池参数修改的成本以及多维度监控这两个方面降低了故障发生的概率。希望本文提供的动态化线程池思路能对大家有帮助。