智能驾驶产品开发中如何贯彻“正向开发”理念

摘要:

基于演绎法的正向开发理念,能够让智能驾驶产品在充分满足用户需求,保证产品质量的同时,确保开发目标合理且得到落实。

前段时间,微博CEO吐槽理想L9智能驾驶“行驶轨迹不居中”,在网上引发了热烈讨论。目前,问题的原因已得到澄清:维保时碰到摄像头,产生微小误差,导致远端感知产生较大偏差;理想后续会升级固件,解决该问题。

不过,从广大网友的发言来看,理想的智能驾驶确实存在“车道不居中、遇到大车不避让”的问题,希望理想后续能够优化。

我们认为,遇到问题后及时解决固然是好的,但如果能在一开始就把问题消灭在源头,那么用户对产品的体验会更好。

如果能贯彻“正向开发”的理念,理想智能驾驶的上述问题完全可以避免:摄像头安装误差对感知效果的鲁棒性,在前期产品设计和需求阶段,就可以明确要求;车道居中和大车避让的需求,作为市场上已有的成熟案例,也是可以在功能需求中明确定义的,没有必要等问题出现了再去优化。

引言

从智能驾驶的量产化进程来看,目前基本的单车道级L2功能已经普及,高速NOA功能逐渐趋于标配,城市NOA功能也逐渐铺开,但是,我们也看到,整体而言,智能驾驶产品的效果和用户体验并不能让人完全满意。

用户体验不佳的原因有很多,如软硬件协同没做好、为了控制成本而把硬件减配做得太激进,还有一个极容易被忽略但又直击本质的原因是:缺乏正向开发理念,对汽车行业的开发流程不够敬畏。

以智驾硬件方案的定义为例,需要多少颗摄像头、多少颗毫米波雷达、是否需要激光雷达、计算平台的AI算力应该多大、选用什么芯片更合理,市场上大多数玩家会从归纳法思维出发,直接套用市场上已有的传感器方案和计算平台,实现现有方案对应的功能:

“通过XXX传感器配置和XXX计算平台,可以实现XXX功能,可以达到X级智能驾驶。”这属于“先有果后有因”的逆向开发思路。

这种通过模仿、先有方案后有功能的思路,不仅容易造成产品同质化,更会导致功能受限,难以实现具有自身特色与亮点的新功能。

正确的做法应该是:从演绎法的思维出发,基于正向开发理念,从产品需求出发,正向定义出满足功能需求的传感器配置方案,并匹配相应的计算平台:

“因为要满足XXX功能,实现LX级智能驾驶,因此需要XXX传感器配置和XXX计算平台。”这是一种基于演绎法思维的开发理念,强调从本质和源头出发。

本文将从智能驾驶开发的一般流程出发,并通过硬件方案和软件方案的正向定义,结合项目实例,说明如何在智能驾驶开发过程中贯彻正向开发的理念。

一 正向开发的优势
 

我们先谈一个跟正向开发相对的概念:逆向开发。

逆向开发,即先锁定固定的配置、技术,然后再反推这些配置和技术能够实现什么样的功能。逆向开发表面上能够降低开发成本、缩短开发周期,因为一切都是对现有产品的“拿来主义”。

但是,逆向开发出来的产品,上限永远只能是别人家已有的方案,并且由于缺乏对产品的深刻理解,只“知其然”,不能“知其所以然”,导致产品质量难以保证,并且产品效果难以提升。

同时,逆向开发过程中如果出现技术难题,可能会无法解决,从而出现项目整体停滞的情况,原因就是逆向开发的本质是归纳和复刻,缺乏正向开发所具备的对产品整体的深刻理解,以及对各项技术的整体把控。

以热门话题“去高精地图”为例,如果采用逆向开发的理念,围绕是否配置高精地图,可能会有一轮又一轮的多部门讨论、开会、决策,最后公司领导拍板:“高精地图太贵了,要去掉,但是要保证功能不打折。”

在逆向开发的认知中,城市NOA功能不是目的,是否需要高精地图才是最大的问题。但是,实际上,在感知算法的水平不足的情况下,缺乏高精地图,是很难实现城市NOA等高阶功能的。

相比之下,正向开发理念将开发目标回归到需求层面,所有的设计和后续开发工作,都是为了满足用户需求,达成产品效果。

还是以“去高精地图”为例,如果采用正向开发的理念,思路就会变成这样:因为要搭载城市NOA功能,所以要么提升感知算法水平,要么让高精地图更精准,应该综合评估哪种方式更容易实现、成本更低。

在正向开发理念中,高精地图不是一个问题或者结论,而是一种措施和手段,最终目标是实现城市NOA功能,而不是解决高精地图的有无问题,因为除了高精地图,还会有其他多种因素,影响城市NOA功能的落地。

正向开发需要从零开始,对产品整体和开发过程的每一步都有深入的理解和完整的把握。虽然看起来正向开发需要更长的开发周期和更高的成本,但当整体流程打通后,正向开发的优势会显而易见:

它能够帮助开发者更好地理解用户需求、关注用户体验,并将需求和开发目标贯彻始终,从而提升产品质量和用户满意度,进而提高产品的竞争力和市场占有率。

不仅能确保产品开发目标得到完全落实,从根源上提升产品实力,还能让整体开发过程有序、严谨,项目的关键节点更容易得到保证,从而顺利达成预期的产品和项目效果。

如果从哲学的维度来说,正向开发更像是一种“道”,逆向开发更像是一种“术”。短期来看,“术”可以解决一些问题,但长期主义者,更应该去追求“道”,通过正向开发理念,把目标聚焦在根源,开发出经得起时间考验的产品。

二 智能驾驶的正向开发流程
 

基于正向开发的理念,在智能驾驶的开发过程中,可以借鉴软件开发的V型流程,形成适用于智能驾驶开发的V型流程体系,如图1所示。

图片

图1 智能驾驶的V型开发流程

可以看到,按照工作流的顺序,智能驾驶V型流程依次包含产品设计与定义、系统分析与设计、硬件分析设计、软件分析设计、硬件开发、软件开发、软件模块测试、台架仿真测试、实车测试等关键阶段。

图1的开发流程是典型的正向开发流程,智能驾驶方案从产品设计与定义开始,经过对智驾系统的详细分析与架构设计,将开发目标传递到硬件和软件层面,硬件和软件分别根据产品需求,开展具体的开发工作;再经过软件测试、台架测试、实车测试等不同等级的测试验证,确认达到产品开发目标,最终完成开发任务并交付。

产品设计与定义通常由产品经理负责,基于市场发展和用户调研,结合公司战略和技术水平,并考虑法规政策限制,完成功能原理、逻辑流程、场景分解、关键参数等,形成产品需求文档(Product Requirement Document,PRD)。

系统分析与设计通常由系统工程师或架构工程师负责,根据PRD、法规和技术标准,制定系统架构、功能状态机、软硬件接口、信号定义、详细性能参数等,形成系统技术规范(System Technical Specification,STS)。

硬件分析与设计通常由硬件工程师负责,根据产品需求和系统技术规范,制定硬件详细需求与方案,包括硬件的型号、参数和技术规范等,形成零部件技术规范(Component Technical Specification,CTS)。

软件分析与设计通常由软件算法工程师负责,根据产品需求和系统技术规范,制定软件详细需求与方案,形成软件需求说明书(Software Requirement Specification,SRS)。

硬件开发包括各类传感器以及智驾域控制器的开发,通常由专业的硬件供应商完成,但也有主机厂会参与开发部分硬件,如激光雷达、毫米波雷达等。

软件开发包括操作系统、中间件和应用层算法等模块的开发,是目前行业内争夺和竞争最为激烈的环节,主机厂想要自研、Tier 1想要把控、各类算法供应商想坚持黑盒,但最终都会完成各类功能的软件算法模块。

硬件与软件开发完成后,进入到测试和验证阶段。首先在软件层面搭建软件测试环境,设计测试用例与脚本,制定软件模块测试方案,并完成软件模块测试;然后将智能驾驶的软件算法搭载到控制器上,搭建台架测试环境,完成基于台架的集成仿真测试,又称为硬件在环测试(Hardware-In-Loop,HIL);最后,将所开发的智能驾驶系统,装载到实车上,通过场地和道路测试,最终验证智能驾驶产品的效果,包括功能、性能、交互、用户体验等内容。

可以看出,对于正向开发来说,智能驾驶的开发应该严格遵循图1所示的V型流程,在产品设计与定义阶段,明确产品需求与开发目标,并逐层传递到具体的开发工作中,然后再逐步集成化测试,在整车层面验证产品达到目标的效果。

不过,在现阶段,由于市场竞争激烈、缺乏统一规范等原因,智能驾驶实际的开发过程,往往难以遵循正向开发流程,出现了一些违背正向开发理念的做法,导致产品质量难以保证,用户体验不佳,并增加了大量的改进成本。

下面,我们分别从硬件方案和软件方案2个方面,展开讲述在智能驾驶开发过程中,如何按正向开发流程开展工作,并避免出现简单归纳法思维以及逆向开发的情况。

三 硬件方案的正向定义

【本文提到的硬件方案,有些已经是众所周知的知识,但我们仍希望通过本文的解释,能让读者“知其然,更知其所以然”,获得“先有产品定义,后有硬件方案”的正向开发理念。——作者注】 

我们经常在发布会上听到这样的说法:“我们的产品配置了激光雷达,拥有三十多个传感器,还用了先进的高算力芯片,是先进的智能驾驶。”

也经常在工作中听到这样的说法:“我们去和英伟达/地平线合作,先把芯片定下来,再看看能做到什么程度。”

甚至会听到公司高层这么说:“你们去看看小鹏/蔚来/理想/大疆的选型方案,我们跟他们用一样的,效果应该差不多。”

以上现象的背后,是一种典型的硬件方向逆向开发的思维方式。在逆向开发的认知中,“配置了高端的硬件,就有了高端的智能驾驶;把市场上别人用的硬件方案归纳一下,选择差不多的方案,就能做出类似的效果”。

但事实很可能是:你用8M像素的摄像头,做出的功能体验不一定比得上别人5M摄像头的效果;你用100TOPS算力的芯片,实现的功能未必有别人30TOPS芯片实现的功能多。

这种情况与软、硬件的综合能力有关,但更本质的原因还是在于:没有按照正向开发的思路,前期开发目标不明确。

根据前面提到的正向开发流程,在定义硬件方案前,更重要的是做好产品层面、系统层面的分析、设计与定义。也就是说,硬件方案应该是服务于功能需求、性能要求和产品整体开发目标的,应该是“需求先行”,而不是“硬件先行”。

下面,我们以功能需求展开,说明如何按照正向开发流程,根据功能需求定义硬件(传感器+计算平台)方案。

在九章智驾之前的文章《详解智能驾驶的功能与场景体系》中,已经系统化地总结了目前主要的智能驾驶功能,包含行车功能、泊车功能、主动安全功能等。

智能驾驶的传感器主要包括摄像头、毫米波雷达、超声波雷达与激光雷达,通过在车身的不同位置布置多种类型的传感器,实现对车辆周围区域的检测;广义的传感器还包括地图定位。传感器的分布和作用,大部分人已经非常熟悉,在此不作赘述,直接参考图1即可。

图片

图1 传感器检测范围

智能驾驶各项功能的实现,依赖于传感器对相关区域的检测,因此不同的功能需求,对应着不同的传感器方案。根据各项智驾功能的效果,以及图1所示的传感器检测范围,可以得出各项功能所需的传感器配置,如表1所示。需要说明的是,表1中勾选的传感器配置,是该功能至少需要的传感器,如果成本允许,当然是越多传感器越好。

表1 智驾功能与传感器对应关系

图片

根据表1,在定义传感器方案时,对于行车功能,单车道L2级功能如LCC只需前视摄像头+前向毫米波雷达;多车道L2级功能涉及相邻车道,还需要前、后角毫米波雷达;点到点的领航驾驶功能,需要增加侧视摄像头与后视摄像头,而城区路况更加复杂,因此C-NOA还需要激光雷达。

对于泊车功能时,停车位区域的自动泊车需环视摄像头+超声波雷达,而停车场范围的记忆泊车、智能召唤、自主代客泊车等功能,涉及低速行驶的场景,因此需要增加行车功能相同的传感器。

主动安全功能的传感器,主要与功能所覆盖的方位有关。

在定义传感器配置方案时,通常可以根据产品的功能需求,参考表1的汇总结果,根据功能,逐一确定所需配置的传感器类型。至于传感器的具体参数、型号,则需进一步根据产品性能要求,按照同样的思路来定义。

智能驾驶的计算平台,主要是指域控制器,其重点是SoC芯片与MCU芯片。其中SoC芯片主要用于AI计算,即处理大量的环境感知与定位数据,以及作出任务决策和轨迹规划等;MCU主要负责执行指令,以及安全可靠性。

SoC芯片的最重要任务是处理环境感知与定位信息,因此,智驾方案对SoC的AI算力的需求与环境数据的丰富程度紧密相关。

根据正向开发流程,在传感器配置方案完成后,应该根据各传感器的数据量,评估SoC芯片所需的算力水平。由于各家的算法不同,不同SoC芯片的内部架构不同,因此同一套传感器配置,可能会出现不同的AI算力要求,但算力水平的大概量级,应该是一致的。

例如,单车道L2级智能驾驶只需要前视摄像头与前向毫米波雷达,5TOPS以内的AI算力足以满足;多车道L2级智能驾驶还需要角毫米波雷达,因此需要5TOPS以上的AI算力;高速领航驾驶H-NOA还涉及侧视摄像头的数据,通常需要30TOPS以上的AI算力;城区领航驾驶C-NOA由于需要处理大量的激光雷达点云数据,通常要求AI算力达到200TOPS以上。

表2汇总了现阶段的主要智驾SoC芯片。在确定智驾产品所需的AI算力水平后,可以从表2中,选取相应的SoC芯片,完成计算平台的核心选型。不过,在实际应用中,AI算力只是关键参数,此外还要综合考虑软件与芯片的匹配度、平台成熟度、成本等多种因素,定义出最适合自己的方案。

表2 智驾SoC芯片汇总

图片

以上,就是从功能需求→硬件方案的正向定义方法,这种正向演绎的思维,能够从功能需求出发,在充分理解各传感器用途和算力分布的基础上,定义出最优的硬件方案。

四 软件方案的正向定义
 

在软件方案中,操作系统和中间件往往是成熟的方案,并且难以在产品效果层面直接体现;但应用层算法,尤其是各项功能的实现逻辑和关键参数,是影响智驾产品最终效果的重要因素。

按照正向开发的流程,智能驾驶算法的逻辑和参数,应该是在产品设计与定义阶段提出,经系统分析与设计阶段细化后,传递到软件开发层面。但在实际的开发过程中,往往容易出现需求定义不清、具体模块开发人员不闻不问,随便拍脑袋,甚至直接照搬其他车型方案的情况,导致最终开发出来的功能,偏离最初的开发目标。

下面通过几个功能的真实案例来说明,软件方案的常见逆向开发做法,以及正确的正向开发方式。


案例一:自动泊车APA

某公司的APA功能开发时,由于项目时间紧任务重,在缺乏产品需求和系统关键参数的情况下,算法工程师认为“目前市场上的APA功能已经很成熟,可以直接拿来用”。在简单了解了某款车型的泊车关键参数后,就迅速开展工作,达到了与该车型大概相同的自动泊车效果。

但在实车测试时发现,车辆泊车完成后的位置,不能够根据周围环境自动调整,导致在周围有障碍物时,有时距离障碍物过近,不方便用户开门下车。并且,在泊车过程中,多次出现方向盘大幅左右晃动、车身不稳的情况。

根源就是因为软件参数不是通过正向开发得到的,而是工程师归纳式简单参考的结果。

原本可以通过正向开发避免的问题,由于急功近利的逆向开发方式,导致泊车功能缺乏亮点,无法让用户满意,没有达到预期的产品效果。

对于这种情况,按照正向开发的流程,首先应该考虑的是在产品设计与定义阶段,通过竞品分析、用户调研等方法,提前考虑到泊车过程中对舒适度的要求,明确对横向控制稳定性的要求,以及泊车完成后的车身位置要求。即使项目时间紧张,也可以压缩各阶段的项目周期,而不能直接“裁剪”掉最重要的源头阶段。


案例二:自适应巡航ACC

有一次,ACC功能开发过程中,我们遇到了ACC目标车速变更和ACC跟车停止逻辑的问题。

在开发ACC功能时,我们团队的产品经理经过市场对标和用户体验分析后,在产品需求中明确提出:用户使用ACC功能时,通过“短按”方向盘的车速调节按键,控制目标车速按步长5kph不变化,通过“长按”按键,控制目标车速按步长1kph变化。

原因是,在道路中行驶时,车速变化1kph的场景极少且没有明显意义,因此通过“长按”的方式来控制;车速变化5kph对于改变车速更有意义,因此通过“短按”这一更为简单的方式来控制。

但是,在开发过程中发现,负责对应开发模块的工程师,忽略了产品需求,通过自己的判断和市场上某一款车型的做法,私自更改产品需求,导致开发结果偏离目标。

这种简单的经验式归纳,直接导致该功能的效果是由软件需求反向影响产品需求,也降低了产品效果。虽然最终得到了改正,但对项目整体来说,产生了额外的成本。

另外,ACC控制车辆停车时,出于功能一致性和连续性的考虑,产品需求中要求在任何时候,用户踩下制动踏板,ACC功能都应该完全退出,但在开发过程中,负责对应模块的工程师,忽略了产品需求,自行定义为“车辆静止状态下,哪怕用户踩下制动踏板,ACC功能仍然能保持”。这不仅违背了功能整体逻辑,也额外增加了软件工作量。

以上情况,虽然开发过程是按照正向流程,产品→系统→软件,但在执行过程中,软件模块的开发人员仍没有意识到正向开发的重要性,按照个人经验去逆向定义甚至忽略产品的需求,导致偏离开发目标,也导致项目的时间和人力成本增加。

这种是个典型的“有流程,但没有意识”的案例。很多时候,公司高层和项目负责人已经认识到正向开发的重要性,并且制定了具体的工作流程,但公司的一些研发人员却没有正向开发的意识,仍然按照个人经验,照搬过去的做法,导致正向开发难以完全贯彻落实,新产品的亮点难以得到百分百地呈现。

针对这种意识、观念层面的问题,我们能做的就是首先在团队整体明确正向开发的理念和方法,然后去培养工程师的正向开发思维,通过团队的影响力,带动个人的意识提升。

案例三:高速领航H-NOA

H-NOA功能开发过程中,我们遇到了默认车道策略和进入匝道前变道时机的问题。

团队在定义H-NOA功能时,对默认的行驶车道没有作出明确定义,仅要求“在合理的车道中行驶”。算法人员在开发时,为降低感知的难度,将默认车道设定为高速公路的最左侧车道。

实际上,根据大量老司机的驾驶经验,以及《道路交通安全法》的要求,高速公路中的长时间行驶车道应该是左侧第二车道,车辆不应该长期保持在最左侧车道行驶。

同样,对于进入匝道前的变道逻辑,前期也没有作明确定义,仅要求“能够在进入匝道前,变道至缓冲车道或最右侧车道”。算法人员在缺乏沟通和调研的情况下,对变道时机的参数定义过于激进,导致测试时,多次出现无法成功进入匝道的情况。

这种情况是由于在项目前期缺乏全面的考虑,导致对产品的某些参数缺乏定义,具体开发时缺乏依据。

按照正向开发流程,在产品和系统层面,相关人员应该尽可能地全面定义各项关键参数;对于NOA这类相对复杂的功能,如果前期确实遗漏了某些参数的定义,那么具体模块的开发人员在缺乏依据时,应该主动向产品或系统人员确认、沟通,而不是自作主张地“拍脑袋”。

前期产品需求全面细致,各具体模块负责人员主动沟通,这样才能让正向开发的流程更好地推进,产品效果得到保证;否则,如果需求定义不清,后续模块人员自作主张,那么实际上又变成了逆向开发的模式,正向开发也就成了表面文章。

五 结语
 

以上,就是智能驾驶的正向开发方法,以及如何在实际工作中,贯彻正向开发理念的一些理论和经验总结。基于演绎法的正向开发理念,能够让智能驾驶产品在充分满足用户需求,保证产品质量的同时,确保开发目标合理且得到落实。

不过,本文的内容属于基本的思路和方法论,在具体的产品开发过程中,还需根据实际情况,如开发能力、成本、周期、资源等,灵活定义方案,及时调整,作出最合理、能落地的选择。

来源 | 九章智驾

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/208886.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

二级指针

*代表指针变量。int*为p的类型。故pp第一个*表示pp为指针int** pp,指向p的二级指针。 p中储存a的地址,pp中储存p的地址。 打印,printf中**pp的表示:pp中储存的是p的地址,第一个*解引用地址p表示p的内容,p的…

微服务学习|初识Docker、使用Docker、自定义镜像、DockerCompose、Docker镜像仓库

初识Docker 项目部署的问题 大型项目组件较多,运行环境也较为复杂,部署时会碰到一些问题 依赖关系复杂,容易出现兼容性问题 开发、测试、生产环境有差异 Docker如何解决依赖的兼容问题的? 将应用的Libs (函数库)、Deps (依赖)配置与应用…

读像火箭科学家一样思考笔记06_初学者之心

1. 专业化是目前流行的趋势 1.1. 通才(generalist)是指博而不精之人 1.2. 懂得的手艺越多,反而会家徒四壁 1.2.1. 希腊谚语 1.3. 这种态度代价很大,它阻断了不同学科思想的交融 2. 组合游戏 2.1. 某个行业的变革可能始于另一…

【计算思维】蓝桥杯STEMA 科技素养考试真题及解析 2

1、兰兰有一些数字卡片,从 1 到 100 的数字都有,她拿出几张数字卡片按照一定顺序摆放。想一想,第 5 张卡片应该是 A、11 B、12 C、13 D、14 答案:C 2、按照下图的规律,阴影部分应该填 A、 B、 C、 D、 答案&am…

WPF树形控件TreeView使用介绍

WPF 中的 TreeView 控件用于显示层次结构数据。它是由可展开和可折叠的 TreeViewItem 节点组成的&#xff0c;这些节点可以无限嵌套以表示数据的层次。 TreeView 基本用法 例如实现下图的效果&#xff1a; xaml代码如下&#xff1a; <Window x:Class"TreeView01.Mai…

链表OJ--上

文章目录 前言一、反转链表二、移除链表元素三、链表中倒数第K个结点四、相交链表五、链表的中间结点 前言 一、反转链表 力扣206&#xff1a;反转链表- - -点击此处传送 思路图&#xff1a; 方法一&#xff1a;改变指向 方法二&#xff1a; 代码&#xff1a; //方法一 /…

【计算机网络笔记】路由算法之层次路由

系列文章目录 什么是计算机网络&#xff1f; 什么是网络协议&#xff1f; 计算机网络的结构 数据交换之电路交换 数据交换之报文交换和分组交换 分组交换 vs 电路交换 计算机网络性能&#xff08;1&#xff09;——速率、带宽、延迟 计算机网络性能&#xff08;2&#xff09;…

【MybatisPlus】简介与使用

MyBatisPlus 1.简介 MyBatisPlus&#xff08;简称MP&#xff09;是一个MyBatis的增强工具&#xff0c;在MyBatis的基础上只做增强不做改变&#xff0c;为简化开发、提高效率而生 官网&#xff1a;https://baomidou.com/ MyBatis-Plus特性&#xff1a; 无侵入&#xff1a;只…

2023亚太杯数学建模B题思路分析 - 玻璃温室中的微气候法规

1 赛题 问题B 玻璃温室中的微气候法规 温室作物的产量受到各种气候因素的影响&#xff0c;包括温度、湿度和风速[1]。其中&#xff0c;适 宜的温度和风速是植物生长[2]的关键。为了调节玻璃温室内的温度、风速等气候因素 , 温室的设计通常采用带有温室风扇的通风系统&#xf…

laravel引入element-ui后,blade模板中使用elementui时,事件未生效问题(下载element-ui到本地直接引入项目)

背景 重构公司后台项目&#xff0c;使用了dcat-admin&#xff0c;但是dcat-admin有些前端功能不能满足需求。因此引入element-ui进行相关界面的优化 具体流程 1.下载element-ui到本地 2.进入如下目录 打开 node_modules\element-ui\lib 复制index.js 打开 node_modules/ele…

【 顺序表经典算法—移除元素和合并两个有序数组】

提示&#xff1a;文章写完后&#xff0c;目录可以自动生成&#xff0c;如何生成可参考右边的帮助文档 目录 前言 经典算法OJ题1&#xff1a; 移除元素 解法一、逐个判断 解法二、双指针覆盖 经典算法OJ题2&#xff1a; 合并两个有序数组 OJ题分为两个类型&#xff1a; 总结 前言…

内存可见性与指令重排序

文章目录 内存可见性内存可见性问题代码演示JMM&#xff08;Java Memory Model&#xff09; 指令重排序指令重排序问题代码演示指令重排序分析 volatile关键字volatile 保证内存可见性 & 禁止指令重排序volatile 不保证原子性 在上一节介绍线程安全问题的过程中&#xff0c…