对于并行和并行概念上的理解与总结

简介: 并行和并行概念上的理解与总结

并行的基本概念 — 为什么需要并行?
1、业务要求:业务上需要一个逻辑执行单元
比如:一个服务端需要处理多个客户端的请求;JVM虚拟机启动后,运行多个线程,包括启动Main函数的线程、JIT即时编译、GC等等;
串行处理多个客户端请求实现复杂;
单线程需要处理任务调度的问题;
进程要比线程更重,开销更大。

2、并行在多核CPU上能够提高性能。
并行计算只适用在图像处理和服务端编程两个领域。两者都属于计算密集型,比如数据挖掘、数据分析,多核运行要比单核运行速度更快。
客观原因:摩尔定律失效,导致多核CPU的产生,使并行技术流行。计算机CPU的发展已经陷入了瓶颈,单核4GHZ的芯片已经到达极限,最终使计算机往多核处理器方向发展。

并发的基本概念
同步:会一直等待请求返回;
异步:异步调用后,可以进行后续工作处理,无需等待结果。
并行:同一时间内间隔,两个线程同时执行,比如垃圾回收时启动多个线程并行处理,用户需要等待。
并发:交替做不同的事情,比如两个CPU,一个CPU处理用户线程,另一个CPU则处理GC线程;
临界区:表示一种公共资源或共享数据,是一种被保护控制的数据,当有线程正在使用数据时,其它线程必须等待该线程释放。
阻塞和非阻塞用于形容多线程在使用临界区时的相互影响。
阻塞:当一个线程占用了临界区的资源,其它的线程必须在临界区中等待,等待会导致线程挂起。如果占用资源的线程一直不释放,其它阻塞在临界区的线程一直不会工作。
非阻塞:允许多个线程同时访问临界区,只要保证不破坏数据。
死锁:对于阻塞的线程,进入临界区后,有可能会发生死锁现象。死锁将会导致系统挂起,服务不可用。死锁产生的必要条件是一个线程抢占到资源而没有释放。
活锁:相对于死锁,两个线程:线程A和线程B,同时需要资源A和资源B;而线程A拿到资源A,线程B拿到资源B,但不能工作,两个线程又同时分别释放掉资源,再次抢占相互释放出来的部分资源,循环往复,始终无法进行正常工作。活锁的问题相比死锁更难排查。
饥饿:是指某一个或多个线程因为种种原因无法获得足够的资源,导致一直无法执行。线程执行具有优先级,当多个线程同时阻塞在临界区,系统会先调度优先级高的线程,而优先级很低的线程因为分配不到足够的资源,系统可能会调用不到,导致线程饿死。

并发级别
阻塞:当一个线程进入临界区后,其它线程必须等待。相对于非阻塞,它是一种悲观策略,多个线程进入临界区修时可能会改坏数据,所以只允许一个线程进入临界区修改数据。
无障碍:
是一种最弱的非障碍阻塞调度。
线程可以自由进入临界区,相对于阻塞,它是一种乐观调度,即它允许所有线程进入临界区读写数据。
但它采取的是宽进严出的策略。当线程退出时,如果有数据竞争,就会先回滚这条数据,并不断的重试,直到获取到正确的数据为止;如果没有数据竞争,会在有限步内完成操作。
无障碍的场景下,相当于获取一个数据快照,直到获取到正确的数据为止。
无锁
必须是无障碍的:无障碍允许所有线程进入临界区,但并不能保证每个线程都能正常退出,当线程之间出现相互干扰,就会不断的一直重试,导致线程无法正常退出临界区,就会造成系统卡死的情况。
制约条件:保证有一个线程可以胜出。即在数据竞争中,在临界区的线程至少有一个竞争成功,必然会顺利退出。
无等待
无锁、要求所有线程都必须在有限步内完成,不限制线程进入临界区,并行级别最高,能够发挥系统性能至最高、无饥饿的,不会让所有线程都等待在临界区
无等待的一种实现情况:
所有的读线程都是无等待的,而写线程修改的是原始数据的副本,写的过程也是无等待的,最终写线程将修改后的数据同步覆盖到原始数据。
根据阿姆达定律和古斯塔夫森定律,阿姆达尔定律:增加CPU不一定能提高并行化效率,提高串行化比例,合理增加并行数,才能得到最大的加速比。古斯塔夫森定律:有足够的并行化数量,要提高串行化效率,只要增加CPU数量就能够提高程序的性能,因此其加速比和CPU的个数成正比关系。

相关文章
|
网络协议
用 ipv6 和端口号发起 http 请求
用 ipv6 和端口号发起 http 请求
java数据结构,线性表链式存储(单链表)的实现
文章讲解了单链表的基本概念和Java实现,包括头指针、尾节点和节点结构。提供了实现代码,包括数据结构、接口定义和具体实现类。通过测试代码演示了单链表的基本操作,如添加、删除、更新和查找元素,并总结了操作的时间复杂度。
java数据结构,线性表链式存储(单链表)的实现
|
域名解析 搜索推荐 Apache
服务器301重定向详细教程
301重定向是一种HTTP状态码,用于指示网页已永久移至新位置,对SEO和用户体验至关重要。本文详解了301重定向的作用,包括提升搜索引擎排名和自动引导用户访问新URL。同时介绍了多种设置方法,如通过网站控制面板、Apache的mod_rewrite模块、IIS的URL重写模块等,并提醒注意新URL的准备、链接更新及流量监控。合理设置301重定向有助于网站平稳过渡和长期发展。
1834 7
|
人工智能 运维 Serverless
【云故事探索】NO1:看森马服饰,在阿里云上如何用AI实现创新?
在数字化转型中,云计算成为企业创新的关键驱动力。森马服饰借助阿里云函数计算,应对新零售挑战,实现业务模式重塑和效率提升。面对AI技术落地的困难,如高成本、长决策周期和复杂运维,森马通过阿里云的Serverless解决方案,快速将AI融入核心业务,优化了从设计到营销的全链条流程。通过函数计算,森马降低了AI项目初期的硬件投入和运维难题,提升了设计师的工作效率,将设计时间从3天缩短到30秒,实现了服装设计和营销的智能化升级。
【云故事探索】NO1:看森马服饰,在阿里云上如何用AI实现创新?
|
SQL JavaScript 前端开发
Hive学习-lateral view 、explode、reflect和窗口函数
Hive学习-lateral view 、explode、reflect和窗口函数
720 4
|
Oracle 关系型数据库 MySQL
一文了解PostgreSQL MVCC机制
一文了解PostgreSQL MVCC机制
950 0
|
JavaScript Java 测试技术
宠物店商城小程序+ssm+vue.js附带文章和源代码设计说明文档ppt
宠物店商城小程序+ssm+vue.js附带文章和源代码设计说明文档ppt
168 2
|
Kubernetes API 数据库
容器服务 Pod 处于 CrashLoopBackOff的原因及解决方法
"CrashLoopBackOff" 是 Kubernetes 中 Pod 进入的一种错误状态,通常是由于容器不断崩溃(失败)而触发的重启策略所导致的。以下是 Pod 处于 CrashLoopBackOff 状态的原因及相应的解决方法: ### 原因: 1. **应用错误:** - 容器内部的应用程序崩溃,导致容器退出。 - 应用程序可能因为异常、未捕获的错误、配置问题、依赖缺失等原因导致崩溃。 2. **错误的启动命令:** - Pod 的启动命令或入口点设置错误,导致容器无法正确启动。 3. **资源限制:** - Pod 可能受到内存或 CPU 资源限制,
4288 0
|
测试技术 数据库
基于SpringBoot+Redis的前后端分离外卖项目-苍穹外卖(四)
基于SpringBoot+Redis的前后端分离外卖项目-苍穹外卖(四)
怎么能快速注册商标和域名联系
怎么能快速注册商标和域名联系
231 1