高并发监控[一]:TP90、TP99耗时监控设计与实现

本文介绍了一种计算TP90、TP95和TP99等性能指标的方法,适用于高并发场景下的监控设计。通过使用TreeMap数据结构,实现了耗时的统计和水位线计算,提供了代码实现示例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

高并发监控[一]:TP90、TP99耗时监控设计与实现

背景

性能测试中,我们经常选择TP90TP95TP99等指标项作为性能对比的参考水位, 在本文中,我们给出一种计算 TP90、TP95 和 TP99 等水位线的方法,首先我们解释一下TP90、TP95、TP99的含义.

TP90: 即 90% 的数据都满足某一条件.
TP95: 即 95% 的数据都满足某一条件.
TP99: 即 99% 的数据都满足某一条件.

我们之所以说其“满足某一条件”,是因为在计算的时候,我们既可以向前计算也可以向后计算,例如:

1, 2, 3, …, 98, 99, 100

如上所示,这是一个从 1 至 100 的数列,如果我们想计算其 TP99 的值,其方法为用数列中数值的总个数乘以 99%,即100 * 99% = 99,显然在这个数列中有两个数值满足这个 99 的概念,分别为:
2: 即数列中 99% 的数值都大于等于2
99: 即数列中 99% 的数值都小于等于99
因此,TP90、TP95 或者 TP99 等水位线是有两种含义的,具体选择哪一种,我们可以按需求自己选择。

设计思路

如果我们要计算 TP90、TP95 或者 TP99 等水位线的值,其前提就是需要我们将所有的待计算数据保存并进行排序。首先我们应该用什么数据结构来存储这一系列的值呢?数组?或者列表?实际上,无论我们选择哪一种数据结构,我们都不能假设其长度无限大,因为内存空间是有限的,而且数据结构也有理论上的最大值,但是我们要存储的值的个数却可能是无限的。因此,我们就需要利用有限长度的数据结构存储更多的数值。在这里,数据结构我们选择TreeMap,以计算耗时的 TP90、TP95 或者 TP99 等水位线为例:
<1,1><5,3><6,1><2,2>< 3,3><4,2><7,2><9,3><10,3>

TreeMap<Long,Long>: key为耗时,value为该耗时下的数据个数,TreeMap是红黑色树数据结构实现,可在初始化时指定其key的排序规则(从小到大):
TreeMap<Long, Long> treeMap = new TreeMap<>(Comparator.naturalOrder());

TreeMap<Long, Long> treeMap = new TreeMap<>(Comparator.naturalOrder());

排序后的数据如下:
<1,1> <2,2> < 3,3> <4,2> <5,3> <6,1> <7,2> <9,3> <10,3>
排序完成后我们需要对总的数据量计进行统计,即对TreeMap的value的数据个数进行循环累加统计:

Long total=treeMap.values().stream().mapToLong(o->o).sum();
total:20

接下来完成对TP90、TP95和TP99的index计算:

Double idx90= Math.ceil((double)total*90/100);
idx90:19
Double idx95= Math.ceil((double)total*95/100);
idx95:20
Double idx99= Math.ceil((double)total*99/100);
idx99:20

此时我们可以看到TP90的index为19,TP95和TP99的index为20,根据TreeMap的耗时分部情况如下: 在这里插入图片描述
那如何将index和我们的区间数据进行映射找寻出该区间对应的耗时呢? 我们可以通过对treeMap数据进行一次recordMap转换,recordMap key记录耗时的第一个idx,value则为该耗时数值:

TreeMap<Long, Long> transMap = new TreeMap<>(Comparator.naturalOrder());
AtomicReference<Long> idx= new AtomicReference<>(0l);
treeMap.forEach((key,value)->{
    transMap.put(idx.get(),key);
    idx.updateAndGet(v -> v + value);
}); 

则转换后的数据如下:

{0=1, 1=2, 3=3, 6=4, 8=5, 11=6, 12=7, 14=9, 17=10}

然后可以通过java8提供的floorEntry返回小于或等于给定的键的值映射:

Long total=treeMap.values().stream().mapToLong(o->o).sum();
Double idx90= Math.ceil((double)total*90/100);
Double idx95= Math.ceil((double)total*95/100);
Double idx99= Math.ceil((double)total*99/100);
Map.Entry<Long, Long> idx90Entry = transMap.floorEntry(idx90.longValue());
Map.Entry<Long, Long> idx95Entry = transMap.floorEntry(idx95.longValue());
Map.Entry<Long, Long> idx99Entry = transMap.floorEntry(idx99.longValue());

Long TP90=idx90Entry.getValue();
Long TP95=idx95Entry.getValue();
Long TP99=idx99Entry.getValue();

代码实现

整体代码实现如下:

@Test
public void test03(){
    TreeMap<Long, Long> treeMap = new TreeMap<>(Comparator.naturalOrder());
    // <1,1> <5,3> <6,1> <2,2> <3,3> <4,2> <7,2> <9,3> <10,3>
    treeMap.put(1l,1l);
    treeMap.put(5l,3l);
    treeMap.put(6l,1l);
    treeMap.put(2l,2l);
    treeMap.put(3l,100l);
    treeMap.put(4l,2l);
    treeMap.put(7l,2l);
    treeMap.put(9l,3l);
    treeMap.put(10l,3l);

    TreeMap<Long, Long> transMap = new TreeMap<>(Comparator.naturalOrder());
    AtomicReference<Long> idx= new AtomicReference<>(0l);
    treeMap.forEach((key,value)->{
        transMap.put(idx.get(),key);
        idx.updateAndGet(v -> v + value);
    });

    Long total=treeMap.values().stream().mapToLong(o->o).sum();
    Double idx90= Math.ceil((double)total*90/100);
    Double idx95= Math.ceil((double)total*95/100);
    Double idx99= Math.ceil((double)total*99/100);
    Map.Entry<Long, Long> idx90Entry = transMap.floorEntry(idx90.longValue());
    Map.Entry<Long, Long> idx95Entry = transMap.floorEntry(idx95.longValue());
    Map.Entry<Long, Long> idx99Entry = transMap.floorEntry(idx99.longValue());

    Long TP90=idx90Entry.getValue();
    Long TP95=idx95Entry.getValue();
    Long TP99=idx99Entry.getValue();

    System.out.println("TP90:"+TP90+", TP95:"+TP95+", TP99:"+TP99);
}

转载请注明:https://blog.csdn.net/u012472945/article/details/105611155

<think>嗯,用户想了解Java项目中频繁Full GC的现象、原因和影响。首先,我得回忆下JVM的垃圾回收机制。根据引用[2],Full GC会清理整个堆内存,包括新生代、老年代和元空间。频繁的Full GC肯定会导致应用性能下降,比如停顿时间变长,影响用户体验。 那现象方面,用户可能会注意到应用卡顿,监控工具显示Full GC次数多,内存使用率高,甚至OOM错误。比如引用[3]提到Young GC频繁导致对象进入老年代,进而触发Full GC。所以需要解释现象的时候,要结合监控数据和实际应用表现。 接下来是原因。可能的原因有很多,比如内存分配不合理,老年代空间不足,元空间不足,代码中有内存泄漏,或者显式调用了System.gc()。引用[1]和[3]提到高并发或大数据处理导致对象快速进入老年代,Survivor区太小。这时候需要分点说明每个原因的具体情况,比如大对象直接进入老年代,或者长期存活的对象积累。 然后是影响,主要涉及性能、可用性和资源成本。频繁的Full GC会导致长时间的停顿,影响响应时间,甚至让用户觉得应用卡死。引用[4]强调优化GC的重要性,所以影响部分要突出对用户体验和系统稳定性的威胁。 最后,用户可能需要知道如何排查和解决这些问题。比如检查内存配置,分析GC日志,优化代码减少对象创建。引用[4]提到合理设置堆内存和GC策略,所以优化策略部分需要给出具体的建议,比如调整Survivor区比例,使用G1GC等。 还要注意用户可能没有说出来的需求,比如他们可能遇到了具体的性能问题,需要快速定位原因。所以在回答时要结构清晰,分点列出,便于用户对照检查自己的系统情况。同时,生成的相关问题要引导用户深入探讨解决方案和优化方法,帮助他们进步学习。</think>### Java频繁Full GC的现象、原因及影响分析 #### 、现象描述 1. **应用性能显著下降** 频繁的Full GC会导致应用线程暂停(Stop-The-World),表现为接口响应时间变长、吞吐量降低,严重时可能触发超时或服务不可用[^2][^4]。 2. **监控指标异常** - GC日志中`Full GC`关键字出现频率高,且单次耗时超过1秒(如`Full GC (Ergonomics) 1000ms`) - 老年代内存使用率持续接近100%,或频繁出现内存锯齿状波动[^3][^4] - 系统监控工具(如Prometheus、JVisualVM)显示堆内存无法有效回收 3. **伴随异常现象** - `OutOfMemoryError`错误频繁出现 - 容器化部署时因内存超限触发Pod重启 --- #### 二、核心原因 ##### 1. **内存分配不合理** - **Survivor区过小**:Young GC后存活对象无法被Survivor区容纳,直接晋升老年代 $$ \text{晋升条件} = \text{对象年龄} > \text{MaxTenuringThreshold} \quad \text{或} \quad \text{Survivor空间不足} $$ - **大对象直接分配老年代**:如未设置`-XX:PretenureSizeThreshold`,大数组或缓存对象跳过Eden区 ##### 2. **内存泄漏** - 静态集合类持有短生命周期对象 - 未关闭的数据库连接、文件流等资源 - 第三方库未正确释放Native Memory ##### 3. **GC触发条件** - **老年代空间不足**:Major GC后仍无法满足新对象分配 - **元数据区溢出**:未设置`-XX:MaxMetaspaceSize`时,动态生成类过多(如Spring AOP) - **显式调用System.gc()**:未配置`-XX:+DisableExplicitGC`时可能误触发 ##### 4. **外部因素** - 高并发场景下请求量突增,瞬时产生大量临时对象 - 缓存策略不当,如未设置LRU淘汰机制导致缓存膨胀 --- #### 三、主要影响 | 影响维度 | 具体表现 | |-----------------|--------------------------------------------------------------------------| | **性能** | 99%响应时间(TP99)恶化,吞吐量下降超过50%[^4] | | **可用性** | 网关层触发熔断机制,微服务调用链路中断 | | **资源成本** | 为缓解问题被迫扩容机器,CPU/内存资源浪费 | | **数据致性** | 长时间GC导致分布式事务超时,引发数据回滚 | --- #### 四、排查优化建议 1. **基础排查步骤** ```bash # 查看GC统计(JDK9+) jcmd <pid> GC.class_histogram # 生成堆转储文件 jmap -dump:live,format=b,file=heap.hprof <pid> ``` 2. **关键JVM参数调整** ```ini # 老年代新生代比例 -XX:NewRatio=3 # Survivor区Eden区比例 -XX:SurvivorRatio=8 # 大对象阈值(单位KB) -XX:PretenureSizeThreshold=1024 ``` 3. **高级优化方向** - 使用G1GC替换ParallelGC:`-XX:+UseG1GC` - 启用元空间监控:`-XX:NativeMemoryTracking=detail` - 限制动态类生成:如配置CGLIB缓存策略 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值