国产化软件性能优化技巧，正确顺序是：先压测定位瓶颈，再针对热点优化，最后回归验证。不要一上来就盲调参数——不知道瓶颈在哪，调了也白调。平顶山项目里按这个顺序做优化，下面讲压测定位和热点代码优化的实操路径。
压测要模拟真实业务，不是空打接口。先梳理业务峰值：一天里哪个时段用户最多、哪个操作最频繁（如下单、查询、报表导出）。按真实比例设计压测场景，比如用户登录占三成、查询占五成、提交占两成。
经验是压测从日常峰值的一点五倍开始加压力，每档稳定跑半小时，记录响应时间、吞吐量、资源占用，找到拐点——响应时间突然飙升的那个并发数就是系统瓶颈点。
压测时同时监控四层指标：应用层（CPU使用率、GC频率）、数据库层（慢查询、锁等待）、中间件层（连接池使用率）、系统层（磁盘IO、网络带宽）。哪层资源先打满，瓶颈就在哪层。常见结果是数据库先满——应用代码没慢查询写法，慢的是缺索引。
经验是压测从日常峰值的一点五倍开始加压力，每档稳定跑半小时，记录响应时间、吞吐量、资源占用，找到拐点——响应时间突然飙升的那个并发数就是系统瓶颈点。
压测工具用wrk或JMeter。脚本录一遍真实业务流程，别单压一个接口。单压接口快，组合起来慢，真实场景才暴露问题。
压测要在和生产同配置的环境做。低配测试机压出来的瓶颈，到生产上未必存在。
应用层瓶颈用性能分析工具定位：Java应用用Async Profiler采火焰图，看哪个方法占CPU时间最多。热点通常集中在三类：循环里做数据库查询（N+1问题）、大对象频繁创建（GC压力大）、同步锁竞争激烈（并发上不去）。
火焰图采集要在压测峰值时做。低峰采的火焰图热点不明显，压测时采才能暴露真实瓶颈。
N+1问题最常见也最容易优化：列表页查出一百条记录，每条又单独查一次详情，变成一百零一次数据库访问。改成批量查询一次取回，性能提升十倍。
数据库层热点看慢查询日志：哪条SQL执行时间最长、调用最频繁。优化顺序是先补索引（最立竿见影）、再改SQL写法（避免SELECT *、避免全表排序）、最后看执行计划对不对。经验是八成慢查询加个索引就解决了，不用改业务代码。
索引建好后看执行计划。有些SQL有索引但没走，因为写法问题（函数包裹字段、隐式类型转换）让索引失效。
索引不是越多越好——写频繁的表索引太多会拖慢写入。按查询需求建复合索引，一张表控制在五到十个索引以内。
每轮优化后重新压测，和优化前基线对比：响应时间降了多少、吞吐量升了多少、资源占用降了多少。目标是核心操作响应时间压到可接受范围（如两秒以内），并保留优化记录——下次出问题知道哪些动过。
优化记录写进运维手册。哪次优化改了什么参数，后面出问题好回溯，不重蹈覆辙，团队也少走弯路，效率高，性能稳。
安全的优化：加索引、改SQL写法、调连接池参数。有风险的优化：改业务逻辑、重构核心算法。建议一轮只做一类优化，验证有效再做下一类，避免改了一堆不知道哪个起的作用。
优化完还要建性能基线，以后每次发版都对比，防止新功能把性能拖垮。平顶山项目里把关键接口的响应时间写进监控告警，超过基线就报警，性能问题早发现早处理。
一轮只做一类优化。先补索引验证效果，再调连接池参数，别一次改一堆，最后不知道哪个起了作用。每轮优化后重新压测，和基线对比。
国产化软件性能优化的路径：压测定方向、火焰图找热点、索引和SQL改见效、回归验证收口。按这个流程走，性能问题都能一步步压下来。
优化后效果用数据说话。响应时间降了多少、吞吐量升了多少、CPU占用降了几成，和基线对比写进报告。没有对比，优化就是自我感觉良好。
JVM参数按内存容量配。堆大小不超过物理内存的一半，新生代比例按业务峰值调。参数拍脑袋调，GC频繁反而更慢。
数据库连接池大小按CPU核数配。八核机器配二十到三十个连接够用，配多了反而争抢。连接池不是越大越好。
优化效果写进验收报告。前后压测数据对比，响应时间降多少、CPU降多少，一目了然。这也是后续运维优化的起点。
性能监控常态化。响应时间、错误率每天盯，恶化趋势早发现。
优化后建性能基线，每次发版对比，防止新功能拖垮老性能。
平顶山团队关键是先压测再动手，别盲调参数，否则越调越乱。
18140041855 
