软件测试工程师性能测试题目及答案

软件测试工程师性能测试题目及答案一、单项选择题（共10题，每题1分，共10分）以下关于TPS指标的标准定义，描述正确的是A.每秒内系统能够成功处理完成的有效事务总数量B.每秒内用户向服务端发起的所有请求总数量C.系统在峰值状态下能够承载的最大在线用户总数量D.单个请求从发出到收到完整响应的平均耗时答案：A解析：TPS即每秒事务数，核心统计维度是成功完成的有效事务量，符合性能领域的标准定义。其余选项错误点：B选项描述的是请求数QPS的部分特征，且未限定“成功处理完成”的前提；C选项描述的是系统最大并发承载能力，和TPS属于完全不同的指标维度；D选项描述的是平均响应时间的定义，和TPS无关。负载测试的核心测试目标是A.验证系统在远超额定负载的极端场景下的崩溃临界点B.验证系统在预先约定的预期业务负载水平下，各项性能指标是否满足需求标准C.模拟服务节点宕机场景下系统的可用性表现D.统计系统在零负载状态下的最低资源占用率答案：B解析：负载测试的核心逻辑是模拟真实预期业务负载，校验性能指标是否达标，是性能测试阶段最常规的验证类测试。其余选项错误点：A选项描述的是压力测试的核心目标；C选项描述的是容灾测试的范畴，不属于性能测试的常规目标；D选项描述的是空闲状态基线校验，不属于负载测试的目标。以下选项中，不属于性能测试核心关注指标的是A.接口返回的业务数据100%符合预期的正确率B.全链路业务请求的平均响应时间C.系统峰值状态下的每秒事务处理量TPSD.应用服务器的CPU、内存资源使用率答案：A解析：接口返回数据的正确率属于功能正确性校验维度的指标，不属于性能测试的核心关注范围。其余三个选项都是性能测试中覆盖业务表现、系统承载能力、服务器资源状态的核心指标。在性能测试执行前必须完成的前置准备工作中，描述错误的是A.提前确认所有被测功能点已经通过完整的功能测试，不存在功能性BUGB.提前完成测试环境的配置对齐，尽可能保证测试环境软硬件配置和生产环境一致C.提前清空环境内的无关数据，确保测试执行过程中不会被历史脏数据干扰D.为了尽可能贴近真实场景，可以直接把性能测试的压测流量直接打在生产环境的核心业务链路上，不需要做任何隔离答案：D解析：未经隔离的压测流量直接进入生产环境会导致生产业务被干扰，严重时会引发生产服务宕机，属于性能测试操作的严重违规行为。其余三个选项都是性能测试执行前必须完成的标准前置准备工作。标准的用户侧HTTP请求响应时间的组成部分中，不包含以下哪个环节A.用户在浏览器端的输入操作耗时B.请求数据包从客户端传输到服务端的网络链路耗时C.服务端收到请求后执行业务逻辑的处理耗时D.响应数据包从服务端回传到客户端的网络传输耗时答案：A解析：用户的手动输入操作耗时属于用户在触发请求前的人为操作行为，不属于HTTP请求从发起到完成接收的链路耗时组成部分。其余三个选项都是标准的网络请求响应时间的核心组成环节。性能瓶颈定位的常规排查顺序优先级是A.先排查服务器硬件资源瓶颈，再排查应用服务逻辑瓶颈，最后排查数据库/缓存中间件瓶颈B.先排查数据库/缓存中间件瓶颈，再排查服务器硬件资源瓶颈，最后排查应用服务逻辑瓶颈C.先排查前端页面渲染瓶颈，再排查后端服务所有环节瓶颈D.按照从上层业务到底层硬件的顺序，优先从用户侧感知到的问题点逐层向下排查答案：D解析：性能瓶颈定位的标准排查逻辑是从上层用户可感知的问题点出发，逐层向下追溯底层依赖环节的问题，这样可以避免无效排查，提升定位效率。其余选项错误点：A的排查顺序完全倒置，很容易先排查无关的硬件资源，浪费大量时间；B的顺序同样不符合从上层到下层的排查逻辑；C完全忽略了后端核心链路的优先级，无法快速定位高并发下的核心瓶颈。基准测试的核心定义是A.系统在单用户单请求的无并发场景下，得到的各项性能指标的基础参考值B.系统在10倍预期负载下运行得到的极限性能指标C.系统在混合多种不同业务场景时得到的综合性能指标D.系统在连续运行72小时以上得到的稳定性指标答案：A解析：基准测试是性能测试的基础参考依据，通过无并发的单用户单请求执行，获取环境本身的基础性能基准，作为后续所有负载测试结果的对照标准。其余选项错误点：B描述的是压力测试的极限测试场景结果；C描述的是混合场景负载测试的结果；D描述的是稳定性耐久测试的结果。以下哪项操作不能在性能测试脚本中实现用户请求的真实模拟A.对每次请求中变化的动态参数做参数化处理，避免所有用户请求使用完全相同的参数B.对服务端返回的动态身份凭证、会话ID等内容做关联提取，作为后续请求的入参C.在两次相邻请求之间增加合理的思考时间，模拟真实用户操作时的间隔等待行为D.为了提升压测效率，完全去掉所有请求的校验逻辑，不校验返回结果直接判定请求成功答案：D解析：去掉所有返回结果校验会导致大量实际执行失败的请求被统计为成功，完全失真的测试结果不具备任何参考价值，不能实现真实用户行为的模拟。其余三个选项都是性能脚本开发过程中模拟真实用户行为的标准必要操作。通常情况下，性能测试中判定服务器资源出现瓶颈的通用阈值标准是A.核心业务场景下服务器CPU持续使用率超过70%，内存持续使用率超过80%B.服务器CPU使用率达到30%，内存使用率达到30%C.服务器CPU使用率瞬间冲高到100%后立刻回落1秒D.服务器磁盘空闲空间低于10%答案：A解析：行业通用的服务器资源瓶颈阈值标准就是核心业务运行时CPU持续占比超过70%、内存持续占比超过80%，后续负载提升后资源会出现抢占排队现象。其余选项错误点：B的资源占用率过低，属于系统非常空闲的状态，不存在瓶颈；C的瞬间冲高立刻回落属于正常的业务波动，不属于持续性资源瓶颈；D的磁盘空闲空间不足是磁盘空间耗尽的风险点，不属于性能运行时的资源瓶颈判定标准。以下关于性能测试中“并发”概念的描述，正确的是A.广义并发既包含同一时刻同时发起请求的严格并发，也包含短时间间隔内大量请求陆续发起的准并发场景B.并发用户数的数值永远和系统的TPS数值完全相等C.并发用户数指的是系统注册的所有用户的总数量D.并发用户数指的是所有曾经登录过系统的历史用户总数量答案：A解析：性能测试领域的广义并发定义同时覆盖严格同时点并发和短时间间隔内的准并发场景，符合真实业务流量的特征。其余选项错误点：B的并发数和TPS没有必然相等的对应关系，TPS和请求响应时间、并发数共同相关；C和D描述的是平台注册用户、历史用户的总量概念，和性能测试中的并发用户定义完全无关。一、多项选择题（共10题，每题2分，共20分）以下选项中，属于性能测试常规分类的测试类型有A.基准测试B.负载测试C.压力测试D.浏览器兼容性测试答案：ABC解析：基准测试、负载测试、压力测试都是性能测试体系内的常规测试分类。错误选项D属于兼容性功能测试的范畴，不属于性能测试的类型。性能测试执行过程中，需要同步监控的常见服务端指标包含以下哪些选项A.服务器的CPU使用率、内存使用率、磁盘IO使用率、网络带宽使用率B.数据库的慢查询数量、锁等待时长、连接池占用率C.缓存中间件的命中率、连接数、响应耗时D.被测服务的业务线程池队列等待长度、GC耗时、接口错误率答案：ABCD解析：这四个选项覆盖了服务器硬件资源、数据库、缓存中间件、应用服务四个维度的核心监控指标，都是性能测试执行过程中必须持续采集的核心数据。以下因素中，会直接导致接口响应时间变长的有A.数据库查询语句未加合适的索引，单次全表扫描耗时大幅提升B.业务逻辑中新增了大量无意义的循环遍历计算操作C.网络链路出现丢包重传现象，传输耗时成倍增加D.服务端开启了不必要的安全校验、日志打印等冗余逻辑答案：ABCD解析：四个选项分别从数据库层面、代码逻辑层面、网络层面、服务端冗余逻辑层面说明了导致接口响应时间变长的常见诱因，全部符合性能测试的实际场景特征。全链路性能测试设计过程中，需要重点覆盖的核心业务场景包含A.占日常业务流量比例最高的高频访问场景，比如电商平台的商品列表浏览场景B.对性能敏感度极高的核心支付交易场景C.大流量集中触发的热点场景，比如整点秒杀场景D.占流量占比不足0.1%的非常冷门的后台管理操作场景答案：ABC解析：高频访问场景、核心交易场景、热点秒杀场景都是全链路性能测试中必须重点覆盖的高优先级场景。错误选项D的冷门场景业务占比极低，不会成为系统性能瓶颈的触发点，不属于核心覆盖范围。以下关于性能测试结果报告的描述，正确的有A.性能测试报告中必须明确标注测试环境的软硬件配置信息，避免报告使用者误判结果适配范围B.报告中需要同步呈现所有测试过程中采集到的原始监控数据，以及趋势变化图表C.报告必须明确给出性能测试结果是否符合预设需求的明确结论，不能出现模糊表述D.针对发现的性能瓶颈，报告中需要给出对应的可落地优化建议答案：ABCD解析：以上四个选项全部符合性能测试输出报告的规范要求，是一份专业性能测试报告必须包含的核心内容。性能测试中常见的性能瓶颈类型包含以下哪几类A.服务器硬件资源类瓶颈，比如CPU算力不足、内存占满B.业务逻辑类瓶颈，比如代码存在死循环、锁竞争严重C.中间件配置类瓶颈，比如数据库连接池配置上限过小D.业务需求类瓶颈，比如不合理的实时计算逻辑设计答案：ABCD解析：四类瓶颈分别从底层硬件、代码实现、中间件配置、顶层需求设计四个维度覆盖了性能瓶颈的所有常见分类，符合实际排查过程中的问题分布特征。耐久稳定性测试的执行过程中，需要重点关注的异常现象有A.服务运行过程中出现的内存泄漏问题，内存使用率持续上涨无法自动释放B.连接池资源泄漏，连接数量随着运行时间推移持续上涨直至耗尽C.长时间运行过程中TPS出现逐步下跌的趋势，响应时间持续变长D.长时间运行过程中出现偶发的业务接口报错、数据不一致的现象答案：ABCD解析：以上四个选项都是系统长时间高负载运行过程中非常容易出现的稳定性类异常，都是耐久测试阶段必须重点监控排查的问题。以下关于性能测试脚本开发的描述，正确的有A.脚本中的参数化需要覆盖足够的变量取值范围，避免所有请求命中同一个缓存键值或者同一行数据库数据B.合理设置的思考时间可以让压测流量的分布特征更贴近真实用户的行为分布C.脚本中必须配置足够的检查点，确保所有压测请求的返回结果都是业务执行成功的状态D.不同业务场景的脚本不需要做任何区分，可以全部复用同一套请求内容答案：ABC解析：参数化配置、思考时间设置、请求结果校验都是性能脚本开发的必要规范操作。错误选项D的不同业务场景对应完全不同的用户操作链路，不可能直接复用同一套请求内容，不符合脚本开发的基本逻辑。以下指标组合中，说明系统的性能已经接近承载极限的有A.继续增加并发用户数，TPS的数值不再上涨甚至开始出现下降B.系统平均响应时间突然开始出现大幅上涨，远超预设的需求阈值C.业务请求的错误率开始快速上升，从不足1%涨到超过5%D.服务器的CPU使用率稳定维持在40%左右，内存使用率稳定在50%左右答案：ABC解析：TPS不再上涨、响应时间陡增、错误率快速上升都是系统达到性能拐点、接近承载极限的典型特征。错误选项D的资源使用率处于非常低的空闲状态，说明系统负载很低，完全没有到达承载极限。性能测试上线前的压测风险防控措施，合理的有A.提前为压测流量打特殊标记，全链路所有环节可以识别压测流量，不会影响真实业务数据B.提前制定压测熔断机制，一旦压测过程中出现异常可以立刻切断所有压测流量C.提前协调相关业务侧人员同步压测时间，规避和真实业务高峰的时间重叠D.压测执行前不需要做任何预案，发现问题再临时处理即可答案：ABC解析：流量标记、熔断机制、时间错峰都是性能压测过程中防控风险的标准合理措施。错误选项D没有任何提前预案的压测操作会带来极高的业务风险，完全不符合风险防控的要求。一、判断题（共10题，每题1分，共10分）性能测试中的并发用户数指的是同一时刻同时向服务端发起业务请求的活跃用户数量，不包含已经完成请求等待操作的在线用户。答案：正确解析：这个定义完全符合性能测试领域对并发用户数的标准定义，能够准确区分活跃请求用户和仅登录不操作的在线用户，避免对系统承载能力的计算出现高估。只要系统的TPS数值越高，就说明系统的性能表现一定越好，不需要参考其他任何指标。答案：错误解析：TPS的数值高低需要结合响应时间、错误率、资源使用率等指标综合判断，如果高TPS伴随极高的响应时间和超过阈值的错误率，实际系统的性能表现是不合格的，不能仅靠单一TPS数值判定性能优劣。性能测试执行过程中不需要关注前端页面的渲染耗时，只需要统计后端接口的响应时间就可以得到用户侧的真实体验数据。答案：错误解析：用户侧的真实体验耗时等于后端接口响应时间加上前端页面的DOM解析、资源渲染耗时，很多情况下前端渲染逻辑的不合理会导致用户感知的耗时远超后端接口耗时，完全忽略前端指标会导致性能评估结果失真。基准测试得到的基础性能数据，可以作为后续所有负载测试结果的对照参考，用来判断随着负载升高性能的下降幅度是否合理。答案：正确解析：基准测试的结果是系统在无并发场景下的性能基线，作为参考基准可以很直观的计算出负载提升过程中性能的衰减比例，是性能测试过程中非常重要的参考依据。为了尽可能提升压测的效率，可以直接在执行性能测试的测试机上运行占用大量资源的其他程序，不会影响压测结果的准确性。答案：错误解析：性能测试的测试机本身的CPU、网络资源占用情况会直接影响压测流量的生成稳定性，如果测试机资源被其他程序大量占用，会导致生成的压测流量出现抖动，最终得到的测试结果完全失真。性能测试过程中发现数据库的慢查询数量快速上升，优先排查SQL语句的执行计划和索引配置情况是合理的排查思路。答案：正确解析：绝大多数慢查询问题的根源都是索引缺失、SQL逻辑不合理，优先排查执行计划和索引配置是数据库瓶颈定位的标准优先思路，可以快速定位问题点。所有性能测试场景都必须模拟100%的严格同时点并发，才能得到完全符合真实业务情况的测试结果。答案：错误解析：真实互联网业务的用户请求是离散分布的，几乎不存在100%同时点完全并发的极端场景，完全严格的并发模拟反而会得到过于极端的不符合真实情况的测试结果，常规性能测试只需要模拟符合流量分布特征的准并发场景即可。性能耐久测试的核心目标是验证系统长时间连续高负载运行状态下的稳定性，排查内存泄漏、资源无法自动释放类的隐性问题。答案：正确解析：很多内存泄漏、资源泄漏的问题在短时间的负载测试过程中不会暴露，只有连续长时间运行后，资源被逐步耗尽才会触发故障，耐久测试就是专门用来验证这类长期稳定性问题的测试类型。不同配置的测试环境中得到的性能测试结果，完全可以直接套用到不同配置的生产环境中，结果不会出现任何偏差。答案：错误解析：测试环境的服务器硬件配置、网络带宽、中间件版本等任何一项和生产环境存在差异，都会直接影响性能测试的最终结果，不同环境下得到的性能数据不能直接无差别套用。性能测试的需求梳理阶段，需要同时和产品、开发、运维等多个角色同步确认所有性能指标的预期要求，避免出现不同角色对性能指标的理解不一致的情况。答案：正确解析：性能需求的共识确认是后续性能测试工作能够顺利推进的基础，提前和所有相关角色对齐指标预期，可以避免后续出现测试结果争议的问题。一、简答题（共5题，每题6分，共30分）请简述常规性能测试的完整执行核心流程要点答案：第一，性能需求梳理与指标定义阶段，联合多角色梳理核心业务场景，明确响应时间、TPS、资源使用率等各项性能指标的验收标准，划定测试的覆盖范围；第二，测试环境搭建与基线校准阶段，搭建和生产配置对齐的测试环境，清理无关脏数据，执行基准测试得到基础性能参考值；第三，性能测试脚本开发与调试阶段，完成业务场景的脚本录制、参数化、关联、思考时间配置和返回结果校验，确保脚本可以1:1模拟真实用户行为；第四，分级测试场景执行阶段，按照从低到高的负载梯度依次执行基准测试、梯度负载测试、极限压力测试、耐久稳定性测试，全链路同步采集所有监控指标数据；第五，结果分析与报告输出阶段，汇总所有监控数据识别性能拐点，定位发现的瓶颈问题，输出完整的性能测试报告和优化落地建议。解析：以上五个要点完整覆盖了性能测试从需求启动到最终交付的全流程，每个环节都是必不可少的核心步骤，任何一个环节缺失都有可能导致最终的性能测试结果出现偏差，无法达到测试目标。请简述用户侧的一次完整HTTP业务请求响应时间的核心组成部分答案：第一，网络链路传输耗时，包含用户端发出请求数据包到服务端网卡收到数据包的上行传输耗时，以及服务端处理完成后响应数据包回传到用户端网卡的下行传输耗时；第二，服务端预处理耗时，包含服务端的反向代理、负载均衡设备的请求转发耗时，以及服务端应用层的请求安全校验、身份鉴权等前置逻辑的执行耗时；第三，核心业务逻辑处理耗时，包含服务端执行业务核心逻辑、调用数据库、缓存等各类依赖资源完成业务计算的总耗时；第四，客户端页面渲染耗时，包含用户端浏览器收到完整响应内容后，解析页面DOM结构、加载静态资源、完成页面最终渲染展示给用户的耗时。解析：完整的响应时间拆解维度覆盖了从用户点击触发请求到最终看到完整页面的全链路所有环节，避免了传统仅统计后端接口耗时的片面性，能够更准确的反映真实用户的体验耗时。请简述TPS、并发用户数、平均响应时间三个核心性能指标之间的关联关系答案：第一，在负载较低的阶段，随着并发用户数的逐步增加，系统的平均响应时间基本保持稳定，TPS会随着并发数的提升成近似线性的上涨趋势；第二，当并发用户数上涨到接近系统的处理能力上限时，系统的资源开始出现排队抢占现象，平均响应时间会逐步开始变长，TPS的上涨速度逐步放缓；第三，当并发用户数超过系统的性能拐点阈值之后，系统的处理能力完全饱和，大量请求进入等待队列，平均响应时间会出现陡增，TPS不再继续上涨甚至开始出现下跌，业务错误率同步上升。解析：三者的关联逻辑符合绝大多数互联网分布式系统的性能变化特征，通过三者的变化趋势可以很直观的定位系统的性能拐点位置，准确评估系统的实际最大承载能力。请简述性能瓶颈定位的通用排查思路核心要点答案：第一，从用户侧感知到的问题切入，首先确认出现性能问题的具体业务场景，以及对应场景下的监控指标变化特征，缩小问题排查范围；第二，从外层链路向内层链路逐层追溯，依次排查网络链路、反向代理、应用服务、中间件、数据库各个环节的指标是否出现异常；第三，先定位资源类瓶颈再定位逻辑类瓶颈，优先确认CPU、内存、IO这类硬件资源是否占满，排除资源瓶颈后再深入排查代码逻辑、SQL执行效率这类软件逻辑层面的问题；第四，通过控制变量法验证问题根因，修改单一变量后重新执行测试，确认性能问题是否消失，最终锁定问题的准确根因。解析：这套从外到内、从易到难的排查思路可以大幅减少无效排查的时间投入，提升瓶颈定位的效率，是行业内性能测试工程师普遍使用的通用成熟排查逻辑。请简述基准测试在性能测试体系中的核心作用答案：第一，基准测试可以得到无并发场景下系统的基础性能数据，作为后续所有负载测试结果的统一对照基准，方便计算不同负载下的性能衰减比例；第二，基准测试可以提前校验测试环境本身的性能是否符合预期，避免环境本身配置错误导致后续负载测试的结果全部失真；第三，每一次代码版本迭代、配置修改之后，都可以重新执行基准测试，快速评估变更对系统基础性能带来的影响，及时发现版本迭代引入的性能退化问题；第四，基准测试得到的各项指标基线，可以作为后续性能测试场景设计的参数输入依据，合理设定后续负载测试的梯度量级。解析：基准测试是所有性能测试工作的基础，很多团队忽略基准测试的步骤，直接开始高并发场景的压测，很容易得到完全错误的测试结果，浪费大量的测试时间。一、论述题（共3题，每题10分，共30分）请结合电商大促的实际业务场景，论述全链路性能测试的完整设计思路和落地方法答案：论点：电商大促场景的全链路性能测试不能仅针对单个接口做压测，必须以真实用户的完整业务路径为核心，从需求、场景、管控、校验四个维度搭建完整的测试体系，才能准确模拟大促的真实流量特征，提前发现全链路的性能瓶颈。论据：以常见的电商大促场景为例，首先第一步做性能需求拆解，对齐大促期间的预期峰值业务量级，比如预计大促峰值同时在线用户达到数百万，下单峰值每秒数万笔，将全链路拆解为用户浏览首页、搜索商品、查看商品详情、加入购物车、提交订单、支付完成这6个核心业务场景，按照大促真实的流量分布比例配置每个场景的流量占比，比如首页浏览流量占比40%，商品详情页流量占比30%，下单支付流量占比10%，剩余20%为其他辅助业务流量。第二步做压测流量的隔离设计，给所有压测请求增加专属的流量标记，全链路的网关、服务、数据库、缓存所有环节都可以识别标记流量，压测过程中生成的所有订单、数据全部写入隔离的专用测试库，完全不会对真实生产环境的用户业务数据产生任何干扰。第三步做压测执行的梯度管控，压测流量从预期峰值的10%开始逐步抬升，依次经过50%峰值、100%峰值、120%峰值三个梯度，每个梯度至少稳定运行15分钟以上，全链路同步监控所有环节的性能指标，一旦出现性能指标超出预设阈值的情况立刻触发熔断机制，自动切断压测流量避免影响线上业务。第四步做最终结果的校验，汇总全链路的指标数据，验证所有核心场景的响应时间、TPS、错误率都符合大促的预期标准，确认所有环节的资源使用率都控制在安全阈值以内。结论：这套完整的全链路性能测试设计方案，已经在多个电商平台的历次大促活动中落地验证，可以提前发现全链路中隐藏的跨服务调用瓶颈、分布式锁竞争瓶颈、数据库热点数据竞争瓶颈等单接口压测无法发现的复杂问题，充分保障大促期间整个平台的业务稳定运行。解析：整个方案从真实业务场景的特征出发，完全规避了单接口压测的局限性，同时通过流量隔离和熔断机制把压测的风险降到了最低，具备很强的实际落地参考价值。结合实际工作案例，论述系统性能拐点出现之后的全流程瓶颈定位和根因排查方法答案：论点：当性能测试过程中出现TPS停止上涨、响应时间陡增的性能拐点时，按照逐层递进的排查逻辑逐步缩小问题范围，就可以快速准确的定位到问题的根本原因，避免盲目排查浪费大量时间。论据：以某电商下单场景压测为例，压测过程中当并发用户数提升到200的时候，原本随并发数线性上涨的TPS突然停止增长，从预期的每秒1200笔下单事务稳定在每秒300笔左右，平均响应时间从200ms陡增到800ms，出现了明显的性能拐点。首先第一步排查最外层的服务器硬件资源，检查应用服务器的CPU使用率只有30%，内存使用率只有40%，网络带宽占用率不到10%，服务器硬件层面没有任何瓶颈，排除底层硬件资源不足的问题。第二步排查应用服务内部的指标，查看应用的线程池监控数据，发现核心下单业务线程池的队列长度已经排满，所有200个活跃线程都处于WAITING等待状态，调用栈采样后发现几乎所有线程都卡在获取同一个分布式锁的代码位置，进一步排查业务代码发现，所有用户下单请求都会先对商品的库存行记录加分布式锁，锁的超时时间设置为3秒，大量并发请求同时抢同一把锁，大部分请求都进入等待状态，导致线程全部阻塞。第三步验证根因，把分布式锁的粒度优化为针对单个用户的订单维度加锁，不再抢全局的同一把锁之后重新执行压测，并发数200的时候TPS顺利上涨到了预期的1300，平均响应时间回落至180ms，性能拐点完全消失，确认分布式锁粒度过大就是本次性能拐点的根因。结论：这