性能测试面试题

一、Jmeter工具使用 1. JMeter中如何实现参数关联？比如登录token传递给下一个接口？ 答案话术： JMeter实现参数关联主要用正则表达式提取器或JSON提取器。 具体做法是：在登录接口的请求上右键添加"后置处理器"，选择JSON提取器或正则表达式提取器，提取返回结果中的token值，设置变量名比如${token}。然后在下一个接口的请求头中引用这个变量${token}，就实现了参数传递。 举个例子：登录接口返回{"code":0,"data":{"token":"abc123"}}，我用JSON提取器配置$.data.token提取token值，变量名设为token。后续接口在Headers里添加Authorization: ${token}，就能把登录token传递过去了。 2. JMeter如何模拟多用户并发登录？ 答案话术： 主要通过线程组和CSV数据文件配置实现。 首先准备CSV文件，里面存放多个用户的账号密码，比如user1/pass1、user2/pass2等。然后在线程组中设置并发用户数，比如100个线程。添加CSV数据文件配置元件，引用刚才的CSV文件，配置变量名username和password。在登录接口中引用${username}和${password}变量。 这样每个线程就会从CSV文件读取不同的用户数据进行登录，实现了多用户并发场景。 3. JMeter中的断言有哪几种？你常用哪种？ 答案话术： JMeter常用的断言主要有响应断言、JSON断言、持续时间断言、大小断言等。 我最常用的是响应断言和JSON断言。响应断言主要用来校验返回的状态码、返回文本是否包含特定内容；JSON断言用来校验返回的JSON数据中某个字段的值是否符合预期。 比如电商项目压测下单接口，我会用JSON断言验证返回的订单状态是否为"success"，用响应断言验证响应码是否为200，确保接口正常。 4. JMeter如何实现集合点（并发集合）？ 答案话术： JMeter通过Synchronizing Timer同步定时器实现集合点。 具体做法是：在需要集合的请求上添加Synchronizing Timer，设置集合的用户数，比如100个用户。当达到指定用户数时，这些线程会同时释放，实现真正的瞬时并发。 这个功能特别适合压测秒杀、抢购等场景，能模拟大量用户同一时刻点击下单按钮的情况。 5. JMeter中的线程组有哪几种？有什么区别？ 答案话术： JMeter主要有三种线程组：普通线程组、setUp线程组、tearDown线程组。 普通线程组是最常用的，用来模拟并发用户执行测试场景。setUp线程组在测试开始前执行，一般用来做数据初始化准备。tearDown线程组在测试结束后执行，用来清理测试数据。 我在电商项目中，会用setUp线程组提前创建测试订单数据，用普通线程组执行压测，用tearDown线程组清理测试产生的脏数据。 6. JMeter如何实现阶梯式加压？ 答案话术： JMeter阶梯式加压主要通过线程组的Ramp Up时间配置实现。 比如我要压测订单接口，目标是从50并发逐步加到500并发。我会设置线程数为500，Ramp Up时间设为450秒，循环次数根据需求设置。这样JMeter会在450秒内逐步启动500个线程，平均每秒增加约1个线程，实现平滑加压。 也可以用Stepping Thread Group插件，更灵活地设置每个阶段的并发数和持续时间。 7. JMeter如何查看实时压测结果？ 答案话术： JMeter主要通过几个监听器查看实时结果： 聚合报告可以看到TPS、响应时间、错误率等汇总数据；图形结果可以看到响应时间的波动趋势；活动线程数可以看到当前有多少线程在运行。 我一般会同时添加聚合报告和图形结果两个监听器，实时观察TPS是否达标、响应时间是否正常、有没有错误。不过监听器会消耗性能，正式压测时我会关闭监听器，用命令行模式执行。 8. JMeter命令行模式怎么用？有什么优势？ 答案话术： JMeter命令行模式通过jmeter n t命令执行。 基本语法是：jmeter n t 脚本.jmx l result.jtl e o report目录 其中 n表示非GUI模式， t指定脚本文件， l保存结果文件， e o生成HTML报告。 命令行模式的优势是不消耗图形界面资源，性能更好，能压出更高的TPS。而且方便集成到Jenkins做持续集成，可以定时自动化执行压测。我在电商项目做性能回归测试时，都是用命令行模式跑的。 9. JMeter如何模拟弱网环境？ 答案话术： JMeter主要通过Constant Throughput Timer恒定吞吐量定时器来限制吞吐量，模拟弱网。 具体做法是添加Constant Throughput Timer，设置目标吞吐量，比如设置为600，表示每分钟最多60个请求，相当于每秒1个请求，就能模拟网络很慢的情况。 也可以用Uniform Random Timer添加随机延迟，模拟网络不稳定的场景。这在电商APP测试中很有用，能验证弱网环境下用户下单是否会超时或报错。 10. JMeter如何处理Cookie和Session？ 答案话术： JMeter通过HTTP Cookie管理器自动处理Cookie和Session。 在线程组下添加HTTP Cookie管理器后，JMeter会自动保存服务器返回的Cookie，并在后续请求中自动携带。不需要手动提取和设置，非常方便。 比如电商项目压测，用户登录后服务器会返回Session ID的Cookie，添加了Cookie管理器后，后续的浏览商品、加购物车、下单等请求都会自动带上这个Cookie，保持登录状态。 11. JMeter如何实现动态参数，比如随机生成手机号？ 答案话术： JMeter主要通过函数助手实现动态参数生成。 常用的函数有\ \ Random生成随机数、\ \ RandomString生成随机字符串、\ \ time生成时间戳等。 比如要生成随机手机号，我会用${\ \ Random(13000000000,13999999999)}生成13开头的11位手机号。或者用BeanShell取样器编写Java代码生成更复杂的数据。 在电商项目压测注册接口时，我就用这种方式生成大量不重复的测试账号。 12. JMeter的聚合报告中各项指标含义是什么？ 答案话术： 聚合报告主要包含这些关键指标： Samples是请求总数；Average是平均响应时间；Median是中位数响应时间；90% Line表示90%的请求响应时间；Min/Max是最小最大响应时间；Error%是错误率；Throughput是吞吐量即TPS。 我最关注的是Throughput看TPS是否达标，Average看平均响应时间是否在500ms以内，Error%看错误率是否低于0.1%，90% Line看是否有长尾请求。 13. JMeter如何实现接口加密？比如MD5签名？ 答案话术： JMeter通过BeanShell预处理器实现接口加密。 具体做法是在请求前添加BeanShell PreProcessor，编写Java代码进行加密。比如MD5签名，我会导入java.security.MessageDigest类，对请求参数进行MD5加密，然后把签名结果设为变量，在请求中引用。 在电商项目中，支付接口需要MD5签名验证，我就用BeanShell实现了自动签名，避免每次手动计算。 14. JMeter分布式压测中Controller和Agent的区别？ 答案话术： Controller是控制机，负责管理和分发任务；Agent是压力机，负责执行压测。 在分布式架构中，Controller将测试脚本分发给多个Agent，Agent执行压测后把结果回传给Controller汇总。Controller可以不参与压测只做管理，也可以同时作为一台Agent执行压测。 我们电商项目做大促压测时，用1台Controller控制5台Agent同时施压，模拟几万用户并发下单，单台机器压不出这个量级。 15. JMeter如何限制每秒请求数TPS？ 答案话术： JMeter通过Constant Throughput Timer恒定吞吐量定时器限制TPS。 添加这个定时器后，设置目标吞吐量，单位是每分钟请求数。比如我想限制TPS为100，就设置6000（100\ 60）。JMeter会自动控制请求速度，不让TPS超过这个值。 这个功能在容量规划测试中很有用，可以逐步提高TPS，观察在什么并发量下系统开始出现瓶颈。 16. JMeter中如何处理HTTPS请求？ 答案话术： JMeter处理HTTPS请求很简单，默认就支持。 如果遇到证书验证问题，可以在HTTP请求中勾选"使用KeepAlive"，或者在系统属性中设置忽略证书验证。也可以导入SSL证书到JMeter的密钥库。 我在电商项目压测支付接口时，都是HTTPS协议，直接在URL填https://开头的地址就可以了，没遇到什么问题。 17. JMeter如何实现数据库压测？ 答案话术： JMeter通过JDBC请求实现数据库压测。 首先在测试计划中添加JDBC Connection Configuration配置数据库连接信息，包括数据库URL、用户名密码、驱动类等。然后添加JDBC Request，编写SQL语句执行查询或更新操作。 我在电商项目中，用这个功能压测过订单查询接口，直接对数据库发起SQL查询，跳过应用层，测试纯数据库的性能瓶颈在哪。 18. JMeter的Debug Sampler和View Results Tree有什么用？ 答案话术： Debug Sampler用来查看变量和属性的值，方便调试脚本。View Results Tree用来查看每个请求的详细信息，包括请求参数、返回结果等。 调试脚本时我会用Debug Sampler查看参数关联是否成功，变量值是否正确提取。用View Results Tree查看接口返回的完整JSON数据，确认断言是否准确。 但是正式压测时要删除这些元件，因为会影响性能消耗额外资源。 19. JMeter如何处理返回的乱码问题？ 答案话术： JMeter乱码问题主要通过设置编码格式解决。 在HTTP请求中，可以在"内容编码"中设置UTF 8。如果还是乱码，可以在jmeter.properties配置文件中设置sampleresult.default.encoding=UTF 8。 我在电商项目压测时，有些商品描述返回中文乱码，就是通过这种方式解决的。 20. JMeter压测时发现TPS上不去，响应时间很长，如何排查？ 答案话术： 我会从三个方面排查： 第一是检查JMeter自身，看压力机的CPU、内存是否打满，线程数设置是否合理，脚本中是否有监听器消耗性能。 第二是检查网络，看带宽是否打满，压力机到服务器的网络延迟是否正常。 第三是检查服务端，配合开发查看服务器CPU、内存、数据库等资源使用情况，看是否有慢查询、线程阻塞等问题。 一般都是通过监控工具定位到具体瓶颈点，然后针对性优化。 二、性能测试基础理论 1. 什么是性能测试？性能测试的目的是什么？ 答案话术： 性能测试是通过模拟用户并发访问，测试系统在特定负载下的响应速度、吞吐量、稳定性等性能指标的测试活动。 主要目的有三个：第一是验证系统是否满足性能需求，比如电商大促时能否支撑10万用户同时下单；第二是发现性能瓶颈，定位是数据库慢、CPU高还是其他问题；第三是为容量规划提供依据，评估需要多少台服务器才能支撑业务峰值。 2. 性能测试和功能测试有什么区别？ 答案话术： 区别主要有三点： 第一是测试目标不同，功能测试验证功能是否正确，性能测试验证系统能否承受预期负载。 第二是测试方法不同，功能测试模拟单用户操作，性能测试模拟大量并发用户。 第三是关注指标不同，功能测试关注功能是否可用，性能测试关注响应时间、TPS、资源使用率等指标。 比如电商下单功能，功能测试验证能否成功下单，性能测试验证1万人同时下单系统是否稳定。 3. 性能测试的主要类型有哪些？ 答案话术： 性能测试主要包括四种类型： 基准测试，用小并发验证脚本和数据正确性；负载测试，逐步加压找到系统承载能力上限；压力测试，超过正常负载测试系统极限和恢复能力；稳定性测试，长时间持续压测验证系统是否有内存泄漏等问题。 我在电商项目中，会先做基准测试验证脚本，再做负载测试找性能拐点，然后做压力测试验证极限，最后做稳定性测试跑6小时确保无内存泄漏。 4. 什么是TPS？什么是QPS？有什么区别？ 答案话术： TPS是每秒事务处理数，表示系统每秒能处理多少笔完整的业务事务。QPS是每秒查询数，表示系统每秒能处理多少次查询请求。 区别在于TPS通常包含多个接口调用，是业务维度的；QPS是单个接口的请求数，是接口维度的。 比如电商下单这个事务，可能包括库存查询、订单创建、支付调用三个接口，这算1个TPS但是3个QPS。 一般压测时我们更关注TPS，因为它更贴近实际业务场景。 5. 什么是响应时间？90%响应时间是什么意思？ 答案话术： 响应时间是从发送请求到收到完整响应的时间间隔，通常以毫秒为单位。 90%响应时间又叫90分位值，表示90%的请求响应时间都在这个值以内。比如90%响应时间是500ms，说明有90%的用户请求在500ms内得到响应，只有10%超过500ms。 这个指标比平均响应时间更能反映用户体验，因为平均值会被少数慢请求拉高。我在电商项目中，要求核心接口90%响应时间小于500ms。 6. 什么是并发用户数？和线程数是一个概念吗？ 答案话术： 并发用户数是指同一时刻同时向系统发起请求的用户数量。 并发用户数和线程数在压测工具中通常是等价的，一个线程模拟一个并发用户。但在实际业务中，并发用户数要考虑思考时间，比如用户浏览商品、填写表单的时间，所以真实并发会比在线用户数少。 我在电商项目压测时，如果业务场景是1000个用户每分钟下单一次，考虑60秒思考时间，实际并发可能只有50 100。 7. 什么是性能瓶颈？常见的性能瓶颈有哪些？ 答案话术： 性能瓶颈是指限制系统性能提升的关键因素，是系统资源或设计上的短板。 常见瓶颈包括：数据库层面的慢查询、缺少索引、连接池不够；应用层面的线程阻塞、死锁、内存泄漏；硬件层面的CPU过高、内存不足、磁盘IO慢；网络层面的带宽打满。 我在电商项目中遇到过订单查询接口TPS上不去，定位发现是数据库全表扫描，加了索引后TPS从200提升到2000。 8. 什么是思考时间？为什么要设置思考时间？ 答案话术： 思考时间是模拟用户在操作之间的停顿时间，比如浏览商品页面、阅读详情的时间。 设置思考时间主要有两个原因：第一是更真实地模拟用户行为，用户不会连续不停地点击；第二是控制系统负载，如果不设置思考时间，压测出来的TPS会虚高，不符合实际情况。 我在电商项目压测时，会根据生产日志分析用户平均操作间隔，设置合理的思考时间，通常在2 5秒之间。 9. 什么是吞吐量？吞吐量和TPS有什么关系？ 答案话术： 吞吐量是指单位时间内系统处理的数据量或事务数，是衡量系统处理能力的重要指标。 吞吐量和TPS是等价的，都表示每秒处理的事务数。有时候吞吐量也指网络带宽，表示每秒传输的字节数。 在性能测试中，吞吐量越高说明系统处理能力越强。我在电商项目中，通过优化把下单接口TPS从800提升到1200，吞吐量提升了50%。 10. 什么是性能拐点？如何找到性能拐点？ 答案话术： 性能拐点是指系统性能从平稳上升转为下降或不再增长的临界点，是系统承载能力的上限。 找性能拐点的方法是阶梯式加压，从小并发逐步增加，观察TPS和响应时间的变化。当TPS不再增长或开始下降，响应时间急剧上升，错误率增加时，就到了性能拐点。 我在电商项目压测订单接口时，发现并发从200增加到400时TPS从750涨到800就不再增长，响应时间从100ms涨到500ms，这就是性能拐点，说明系统极限TPS在800左右。 11. 什么是容量规划？如何进行容量规划？ 答案话术： 容量规划是根据性能测试结果，评估系统需要多少硬件资源才能满足业务需求。 进行容量规划的步骤是：第一步明确业务峰值，比如电商大促预计10万笔订单/小时；第二步通过压测得到单台服务器的TPS上限，比如单台800 TPS；第三步计算需要的服务器数量，10万/3600≈28 TPS，但考虑3倍冗余，至少需要4台服务器。 我在电商项目中，通过容量规划为618大促提供了资源评估方案。 12. 什么是性能基线？为什么要建立性能基线？ 答案话术： 性能基线是系统在特定配置和负载下的性能指标参考值，是后续性能对比的基准。 建立性能基线的目的是：第一，为后续版本迭代提供对比依据，评估新功能是否影响性能；第二，发现性能劣化问题，如果新版本TPS下降明显就要排查原因；第三，为线上问题提供参考，快速判断是否性能异常。 我在电商项目中，每个版本上线前都会做性能回归测试，与基线对比确保性能不劣化。 13. 什么是混合场景压测？和单接口压测有什么区别？ 答案话术： 混合场景压测是模拟用户真实业务流程，按一定比例同时压测多个接口。单接口压测只压测一个接口。 区别在于混合场景更接近生产环境，能发现接口间的相互影响和资源竞争。比如电商场景，用户会浏览商品、加购物车、下单、支付，这是一个完整流程。单接口压测可能下单接口TPS达到1000，但混合场景可能只有600，因为其他接口占用了资源。 我在电商项目做性能测试时，会先做单接口找极限，再做混合场景模拟真实负载。 14. 性能测试报告应该包含哪些内容？ 答案话术： 性能测试报告主要包含七个部分： 第一是测试目的和测试范围；第二是测试环境和配置信息；第三是测试场景设计，包括并发数、压测时长等；第四是性能指标要求，比如TPS、响应时间目标；第五是测试结果数据，包括各项指标的实际值；第六是性能瓶颈分析，发现的问题和原因；第七是优化建议和结论。 我在电商项目中编写的性能测试报告都会包含这些内容，并附上监控截图和数据分析图表。 15. 什么是长尾请求？长尾请求对系统有什么影响？ 答案话术： 长尾请求是指响应时间特别长的少数请求，在响应时间分布图中呈现长尾状。 长尾请求会严重影响用户体验，虽然占比小但影响大。比如90%的请求200ms响应，但5%的请求需要5秒，这些用户就会感觉系统很慢。 长尾请求通常是因为数据库慢查询、缓存失效、GC停顿等原因。我在电商项目中，通过优化慢查询SQL、增加缓存，把95%响应时间从3秒降到500ms，消除了长尾。 16. 什么是全链路压测？和普通压测有什么区别？ 答案话术： 全链路压测是在生产环境对真实系统进行压测，通过流量染色和影子库技术避免影响真实用户数据。普通压测在测试环境进行。 区别在于全链路压测更真实，能发现测试环境发现不了的问题，比如生产环境的网络延迟、第三方服务的影响等。但全链路压测技术复杂度高，需要数据隔离和流量染色。 我了解全链路压测的原理，电商大厂在大促前都会做全链路压测验证容量。 17. 性能测试中如何准备测试数据？ 答案话术： 测试数据准备主要有三种方式： 第一是从测试环境数据库捞取真实数据，优点是数据真实可靠。 第二是通过自动化脚本调用业务接口生成数据，比如批量注册用户、创建订单，优点是数据完整符合业务规则。 第三是用数据库存储过程批量造数据，速度快但只适合简单表结构。 我在电商项目压测时，会用自动化脚本提前生成1万个测试用户和10万条商品数据，确保压测时数据充足。 18. 什么是预热？为什么性能测试需要预热？ 答案话术： 预热是在正式压测前，先用小并发跑一段时间，让系统进入稳定状态。 需要预热的原因有三个：第一是让应用预加载数据和类到内存；第二是让数据库缓存热数据；第三是让JVM完成初始化和JIT编译。 如果不预热直接大并发压测，前期数据会不准确，响应时间虚高。我在电商项目中，会先用50并发预热5 10分钟，再正式加压。 19. 性能测试什么时候做？是在功能测试之前还是之后？ 答案话术： 性能测试一般在功能测试基本完成之后进行，因为性能测试需要功能稳定的系统作为基础。 但也可以在项目早期做性能摸底测试，提前发现架构层面的性能风险。大的版本迭代或重要促销活动前，都要做性能测试验证容量。 我在电商项目中，每个迭代版本功能测试完成后会做性能回归测试，618、双11大促前1 2周会做全面的性能压测和容量评估。 20. 性能测试和压力测试是一回事吗？有什么区别？ 答案话术： 不是一回事，压力测试是性能测试的一种类型。 性能测试是一个统称，包括负载测试、压力测试、稳定性测试等多种类型。负载测试是逐步加压找到系统承载能力；压力测试是超负荷运行测试系统极限和恢复能力；稳定性测试是长时间持续压测。 简单说，负载测试是找正常上限，压力测试是找崩溃极限。我在电商项目中，通常先做负载测试找到最佳TPS，再做压力测试验证极限场景下系统表现。 三、性能测试监控 1. 性能测试中主要监控哪些指标？ 答案话术： 性能测试主要监控四个层面的指标： 第一是应用层指标，包括TPS、响应时间、并发数、错误率等业务指标。 第二是服务器资源指标，包括CPU使用率、内存占用、磁盘IO、网络带宽等。 第三是数据库指标，包括数据库连接数、慢查询、锁等待、QPS等。 第四是中间件指标，包括Redis命中率、消息队列堆积量、线程池使用情况等。 我在电商项目压测时，会同时监控这四个层面，全方位掌握系统状态。 2. Grafana+Prometheus+Exporter监控原理是什么？ 答案话术： 这是一套完整的监控体系，工作原理是这样的： Exporter是数据采集器，部署在被监控的服务器上，负责收集系统指标如CPU、内存、磁盘等数据。Prometheus是时序数据库，定期从Exporter拉取数据并存储。Grafana是可视化展示工具，从Prometheus查询数据生成监控大盘和图表。 我在电商项目中，就是用这套方案实时监控20多台服务器的性能指标，可以快速发现哪台机器出现瓶颈。 3. Linux中常用的性能监控命令有哪些？ 答案话术： 我常用的Linux性能监控命令有这些： top命令查看CPU使用率和进程资源占用；free h查看内存使用情况；df h查看磁盘空间使用率；iostat查看磁盘IO读写情况；netstat或ss查看网络连接状态；vmstat综合查看系统资源；dstat可以同时看CPU、内存、磁盘、网络。 如果需要持续监控，我会用watch命令每秒刷新，比如watch n 1 free h实时看内存变化。 4. 如何监控Java应用的JVM性能？ 答案话术： 监控JVM主要用这几个工具： jvisualvm可视化工具，可以实时查看堆内存使用、线程状态、GC情况，还能做线程dump和堆dump分析。 jstat命令行工具，用jstat gcutil查看GC统计信息，包括年轻代、老年代使用率、GC次数和耗时。 jmap用来查看堆内存对象分布，jmap histo可以看哪些对象占用内存最多。 我在电商项目压测时，如果发现响应时间突然变长，会用jvisualvm查看是不是Full GC频繁导致的。 5. 如何判断CPU使用率是否正常？多少算高？ 答案话术： 判断CPU是否正常要结合具体场景： 一般来说，CPU使用率持续在80%以上就算比较高了，需要关注。但也要区分情况，如果是计算密集型应用，压测时CPU高是正常的；如果是IO密集型应用，CPU应该不会太高。 还要看CPU的具体分类，用top命令可以看到user态、system态、iowait等。如果iowait高说明磁盘IO是瓶颈；如果system态高可能是系统调用过多。 我在电商项目压测时，要求正常业务场景下CPU使用率控制在70%以内，留30%余量应对突发流量。 6. 如何监控数据库的性能指标？ 答案话术： 监控数据库性能主要关注这几个方面： 第一是连接数，用show processlist查看当前连接数，防止连接池耗尽。 第二是慢查询，通过慢查询日志找出执行时间超过阈值的SQL。 第三是QPS/TPS，用show global status like 'Questions'查看数据库每秒查询数。 第四是锁等待，用show engine innodb status查看是否有锁冲突。 第五是缓存命中率，查看buffer pool命中率是否够高。 我在电商项目中，会用Grafana+Prometheus+MySQL Exporter实时监控这些指标，设置告警阈值。 7. 什么是慢查询？如何定位慢查询？ 答案话术： 慢查询是指执行时间超过设定阈值的SQL语句，MySQL可以配置long\ query\ time参数，比如设置为1秒，超过1秒的查询就会记录到慢查询日志。 定位慢查询主要两步：第一步用mysqldumpslow工具分析慢查询日志，找出耗时最长、出现次数最多的SQL。第二步用EXPLAIN分析这些SQL的执行计划，看type类型，如果是ALL表示全表扫描，说明没走索引。 我在电商项目压测时，发现订单查询TPS上不去，通过慢查询日志定位到一条SQL没加索引，加上后TPS从200提升到2000。 8. 如何监控Redis的性能？ 答案话术： 监控Redis主要关注这几个指标： 第一是命中率，用info stats查看keyspace\ hits和keyspace\ misses，计算命中率，正常应该在90%以上。 第二是内存使用情况，用info memory查看已用内存和最大内存，防止OOM。 第三是连接数，用info clients查看当前连接数，防止连接数耗尽。 第四是慢查询，用slowlog get查看执行时间较长的命令。 我在电商项目中，会监控Redis的命中率和内存使用，如果命中率低于80%就要优化缓存策略。 9. 压测时发现数据库CPU很高，如何排查？ 答案话术： 数据库CPU高我会这样排查： 第一步用top查看是不是mysqld进程占用CPU最高。 第二步查看慢查询日志，用mysqldumpslow分析是哪些SQL执行慢、频率高。 第三步对慢SQL用EXPLAIN分析执行计划，看是否全表扫描、是否走索引。 第四步检查是否有锁等待，用show engine innodb status查看锁情况。 第五步查看数据库连接数是否过多，连接池配置是否合理。 我在电商项目遇到过订单查询导致数据库CPU 95%，最后发现是SQL没加索引，加上联合索引后CPU降到20%。 10. 如何监控线程状态？什么是线程阻塞？ 答案话术： 监控Java应用线程状态主要用jvisualvm或jstack工具。 jvisualvm可以看到线程的运行状态，包括Runnable运行中、Waiting等待、Blocked阻塞等。jstack可以导出线程堆栈快照，分析线程在做什么。 线程阻塞是指线程处于Blocked状态，通常是在等待获取锁。如果大量线程阻塞，说明有锁竞争或死锁问题。 我在电商项目压测时，发现TPS上不去，用jvisualvm看到50多个线程都是Blocked状态，做线程dump分析后发现是日志打印导致的锁竞争，优化后问题解决。 11. 什么是GC？如何监控GC情况？ 答案话术： GC是垃圾回收机制，JVM自动回收不再使用的内存对象。GC分为Minor GC回收年轻代和Full GC回收整个堆。 监控GC主要用jstat命令，jstat gcutil可以看到年轻代、老年代使用率、GC次数和耗时。 重点关注Full GC的频率和耗时，Full GC会导致STW停顿影响性能。如果Full GC频繁，可能是内存泄漏或堆内存设置太小。 我在电商项目压测时，发现响应时间有尖刺，监控GC后发现每5分钟一次Full GC耗时2秒，优化后Full GC降到2小时一次。 12. 如何判断是否发生了内存泄漏？ 答案话术： 判断内存泄漏主要看这几个现象： 第一是老年代内存持续上升，长时间不下降，用jstat gcutil看Old区使用率。 第二是Full GC频率越来越高，但回收效果越来越差。 第三是应用最终抛出OutOfMemoryError异常。 定位内存泄漏的方法是用jmap做堆dump，然后用jvisualvm或MAT工具分析，看哪些对象占用内存最多、是否被正常释放。 我在电商项目遇到过内存泄漏，通过堆dump分析发现是订单对象被静态Map引用没释放，改用Guava Cache后解决。 13. 压测时如何实时查看应用日志？ 答案话术： 实时查看应用日志主要用Linux命令： tail f命令可以实时查看日志文件末尾新增内容，比如tail f /var/log/app.log。 如果日志量大，可以配合grep过滤关键字，比如tail f app.log | grep ERROR只看错误日志。 如果要查看历史日志，用grep n关键字 日志文件搜索， n显示行号方便定位。 我在电商项目压测时，会同时开几个终端窗口，分别tail应用日志、数据库日志、nginx日志，实时监控有没有报错。 14. 什么是线程池？如何监控线程池状态？ 答案话术： 线程池是预先创建一定数量线程处理任务的池子，避免频繁创建销毁线程的开销。 监控线程池主要关注这几个指标：活跃线程数、队列长度、拒绝任务数。可以通过JMX暴露线程池指标，用Grafana展示；或者用jstack查看线程状态。 如果活跃线程数接近最大线程数，队列很长，说明线程池不够用。如果有拒绝任务，说明线程池已满载。 我在电商项目压测时，发现大量请求超时，监控线程池后发现Tomcat线程池只设了50，改成200后问题解决。 15. 如何监控网络带宽使用情况？ 答案话术： 监控网络带宽主要用这几个命令： ifstat命令可以实时查看网卡的入站和出站流量，单位是KB/s或MB/s。 iftop命令可以看到每个连接的实时流量，类似网络版的top。 nload命令可以图形化展示网络流量曲线。 如果发现网络流量接近带宽上限，比如千兆网卡接近125MB/s，说明网络是瓶颈。 我在电商项目压测时，遇到过响应时间突然变慢，查看网络流量发现接近带宽上限，优化返回数据大小后解决。 16. 压测时发现磁盘IO很高，如何排查？ 答案话术： 磁盘IO高我会这样排查： 第一步用iostat x查看磁盘使用率，如果util接近100%说明磁盘繁忙。 第二步用iotop查看是哪个进程在读写磁盘，定位到具体应用。 第三步分析应用日志，看是不是日志写入过于频繁。 第四步检查数据库，是否有大量磁盘读写操作，数据库缓存是否太小。 我在电商项目遇到过磁盘IO 100%，排查后发现是应用把日志级别设成DEBUG，每秒写几万行日志，改成INFO后IO降到10%。 17. 什么是负载均衡？如何监控负载均衡效果？ 答案话术： 负载均衡是将请求分发到多台服务器，避免单台服务器过载。常见的有Nginx、LVS等。 监控负载均衡效果主要看两个方面：第一是请求分发是否均匀，用Nginx的access日志或监控工具查看每台服务器的请求量是否接近。第二是每台服务器的资源使用率是否均衡，如果某台CPU特别高说明负载不均。 我在电商项目中，用Grafana监控5台应用服务器，发现有一台CPU 80%其他只有30%，排查后发现是Session粘滞导致，改用Redis共享Session后负载均衡了。 18. 如何监控消息队列MQ的性能？ 答案话术： 监控MQ主要关注这几个指标： 第一是消息堆积量，如果消息积压严重说明消费能力不足。 第二是消费延迟，消息从生产到消费的时间间隔，正常应该在秒级。 第三是消费者数量和状态，是否有消费者宕机或消费异常。 第四是吞吐量，每秒生产和消费的消息数。 我在电商项目中，会监控Kafka的消息堆积量，如果超过10万条就告警，说明要增加消费者或优化消费逻辑。 19. 压测过程中如何设置监控告警？ 答案话术： 设置监控告警主要在Grafana或Prometheus中配置： 根据性能指标设置阈值，比如CPU超过80%、响应时间超过1秒、错误率超过1%就告警。 配置告警通知方式，可以邮件、钉钉、企业微信等多种渠道。 设置告警级别，比如CPU 80%是Warning，90%是Critical。 还可以设置告警恢复通知，当指标恢复正常时发送消息。 我在电商项目压测时，设置了10多个监控指标的告警，一旦超过阈值立即通知，能快速响应问题。 20. 如何生成性能监控报告？ 答案话术： 生成性能监控报告主要包含这些内容： 第一是监控指标汇总，包括TPS、响应时间、CPU、内存等关键指标的最大值、平均值、趋势图。 第二是监控截图，把Grafana大盘、JMeter聚合报告等截图放到报告中。 第三是异常分析，压测过程中出现的性能问题、告警记录。 第四是监控数据对比，与性能基线或历史数据对比，评估性能变化。 我在电商项目中，用Grafana可以直接导出PDF格式的监控报告，也会手工整理Word文档包含更详细的分析。 四、性能测试瓶颈分析 1. 压测时TPS上不去可能是什么原因？如何排查？ 答案话术： TPS上不去的原因比较多，我会从这几个方面排查： 第一是压力机本身，检查压力机CPU、内存是否打满，脚本是否有问题，如果单台压不够就用分布式压测。 第二是网络带宽，查看网络流量是否达到上限，压力机到服务器的网络是否正常。 第三是服务器资源，用top、free查看CPU、内存使用率是否达到瓶颈。 第四是数据库，查看慢查询、连接池、索引是否有问题。 第五是应用代码，用jstack查看是否有线程阻塞、死锁。 我在电商项目遇到过订单接口TPS只有200，排查后发现是数据库全表扫描，加索引后TPS提升到2000。 2. 压测时CPU使用率很高怎么办？如何定位分析？ 答案话术： CPU高分两种情况：一种是响应时间短TPS高，这是正常的；另一种是响应时间长TPS低，这需要优化。 定位分析CPU高的方法是：第一步用top命令找到占用CPU最高的Java进程PID。第二步用top Hp PID查看该进程下哪个线程占用CPU最高。第三步把线程ID转成16进制。第四步用jstack命令导出线程堆栈，搜索16进制线程ID定位到具体代码。 我在电商项目遇到过CPU 95%的问题，通过这个方法定位到是日志打印导致的线程阻塞，优化日志框架后CPU降到30%。 3. 压测时响应时间很长怎么分析？ 答案话术： 响应时间长我会从六个方面分析： 第一是服务器硬件资源，CPU、内存、磁盘是否达到瓶颈。 第二是网络问题，网络延迟、丢包、带宽不够。 第三是线程问题，用jstack查看是否有线程死锁、阻塞。 第四是中间件问题，MQ消息堆积、Redis缓存失效。 第五是数据库问题，慢查询、缺少索引、连接数不够。 第六是应用代码问题，用JProfiler分析哪个方法耗时最长。 我在电商项目遇到过订单接口响应时间3秒，通过慢查询日志定位到SQL全表扫描，加索引后降到50ms。 4. 如何定位线程阻塞问题？ 答案话术： 定位线程阻塞主要用jvisualvm或jstack工具。 第一步用jvisualvm连接应用，点击线程标签，查看有多少线程处于Blocked状态。 第二步做线程dump生成快照文件，在文件中搜索"blocked"关键字，统计有多少blocked线程。 第三步查看这些线程的堆栈信息，找到是在等待什么锁、哪行代码导致的阻塞。 第四步分析业务代码，看是否锁粒度太大、是否有不必要的同步操作。 我在电商项目压测时，发现50个线程都blocked，线程dump后发现都在等待日志打印的锁，优化后问题解决。 5. 如何定位数据库慢查询问题？ 答案话术： 定位数据库慢查询分五步： 第一步开启慢查询日志，配置long\ query\ time阈值比如1秒。 第二步用mysqldumpslow工具分析慢查询日志，找出耗时最长、出现次数最多的SQL。 第三步对慢SQL