当前位置：网站首页>(1)性能调优的标准和做好调优的正确姿势-有性能问题,上HeapDump性能社区!

(1)性能调优的标准和做好调优的正确姿势-有性能问题,上HeapDump性能社区!

2022-07-04 12:52:00 【呆萌小新@渊洁】

文章目录
@[toc]
1.什么时候开始介入调优
2.性能调优基本步骤和策略
3. 字符串常有的性能的坑
3.1 源码分析StringBuffer、StringBuilder性能
3.2 String、StringBuffer、StringBuilder性能压测
3.3 String.intern的神奇
3.4 String.intern案例:优化后内存效果
4 正则表达式的坑
5. java序列化:原生序列化
6 NIO原理
6.1 NIO 并发IO场景
6.2 NIO什么情况下不能去用?
7.HashMap的血案与ConcurrentHashMap的正确用法

有性能问题,上HeapDump性能社区!

1.什么时候开始介入调优

·项目开发的初期，过于在意性能优化，反而会让我们疲于浪费精力，不仅不能给系统性能带来较大提升，还会影响到开发进度，甚至获得相反的效果，给系统带来新的问题
我们只需要在代码层面考虑基本场景编程性能出问题地方︰减少磁盘I/О操作、降低竞争锁的使用以及外部服务调用谨慎处理
·开发完成后，一般情况会对系统进行性能测试。产品经理一般会提供线上预期数据，我们在提供的参考平台上进行压测，通过性能分析、统计工具来统计各项性能指标，看是否在预期范围之内。
·项目上线后，我们需要根据线上的实际情况，依照监控指标和统计日志，来观测系统性能问题，发现问题，修复问题。性能关心核心维度
CPU、内存、磁盘I/O、网络、响应时间、吞吐量TPS、QPS

2.性能调优基本步骤和策略

优先兜底保证程序可用,再修复排查调优

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-a6a3DuKQ-1656732438622)(E:\markdown笔记\java\性能调优.assets\image-20220702101602677.png)]$

3. 字符串常有的性能的坑

String、StringBuffer、StringBuilder、intern

Java9在程序中,绝大多数字符串只包含英文字母数字等字符,使用Latin-1编码，一个字符占用一个 Byte。使用Char，一个Char 要占用两个Byte，会占用双倍的内存空间

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TkrFtlZP-1656732438623)(E:\markdown笔记\java\性能调优.assets\image-20220702102307075.png)]$

6 -> 7/8 开发者操作不当可能导致偏移量统计错误,造成栈溢出.因此取消offset,count变量

7/8 -> 9 字符一般是字母类型,性能考量使用byte[]

3.1 源码分析StringBuffer、StringBuilder性能

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-386Irizg-1656732438623)(E:\markdown笔记\java\性能调优.assets\image-20220702102528558.png)]$

StringBuffer 线程安全，但是加了大量的 Synchronized锁.
StringBuilder适合并发环境非竞争字符资源的场景:比如公用的工具类方法.

3.2 String、StringBuffer、StringBuilder性能压测

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wh5yeE3s-1656732438623)(E:\markdown笔记\java\性能调优.assets\image-20220702102817457.png)]$

3.3 String.intern的神奇

Twitter每次发布消息状态的时候，都会产生一个地址信息。当时 Twitter用户的规模，服务器需要32G 的内存来存储地址信息。后来调用String.intern，内存变成几百兆

intern方法:从字符串常量池中查询当前字符串是否存在，若不存在就将当前字符串放入常量池中

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HSJ7UMBt-1656732438624)(E:\markdown笔记\java\性能调优.assets\image-20220702103200952.png)]$

jdk6: 字符串的常量池是放在堆的Perm 区

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Lqi7kVg8-1656732438624)(E:\markdown笔记\java\性能调优.assets\image-20220702103411818.png)]$

JDK7、JDK8:字符串常量池已经从Perm区移到正常的Java Heap区域了。Perm区域太小是一个主要原因．常遇到OOM情况。JDK8已经直接取消了Perm区域，新建立一个元区域MetaSpace

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-R2Z8EEKX-1656732438624)(E:\markdown笔记\java\性能调优.assets\image-20220702103733003.png)]$

3.4 String.intern案例:优化后内存效果

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Bs4TVt6E-1656732438624)(E:\markdown笔记\java\性能调优.assets\image-20220702104333113.png)]$

4 正则表达式的坑

用NFA自动机实现的比较复杂的正则表达式,在匹配过程中经常会引起回溯问题。大量的回溯会长时间地占用CPU,从而带来系统性能开销

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-A2FSXqi7-1656732438625)(E:\markdown笔记\java\性能调优.assets\image-20220702104359487.png)]$

贪婪模式(Greedy)
顾名思义，就是在数量匹配中，如果单独使用+、?、*或[min.max]等量词，正则表达式会匹配尽可能多的内容。例如之前例子: text= “abbc”regex= “ab[ 1 ,3]c”就是在贪婪模式下，NFA自动机读取了最大的匹配范围，即匹配3个b字符。匹配发生了一次失败，就引起了一次回溯。如果匹配结果是“abbbc”,就会匹配成功

独占模式(Possessive)
独占模式一样会最大限度地匹配更多内容;不同的是，在独占模式下，匹配失败就会结束匹配，不会发生回溯问题。之前的例子，在字符后面加一个“+”，开启独占模式.
text=“abbc”regex= “"ab[1,3]+bc 结果是不匹配.结束匹配,不会发生回溯问题

之前案例适合用独占模式。总结正则表达式技巧
少用贪婪模式，多用独占模式贪婪模式会引起回溯问题，我们可以使用独占模式来避免回溯2.减少分支选择类型“(X|Y|Z)”的正则表达式会降低性能，我们在开发的时候要尽量减少使用如果一定要用，可以通过以下几种方式来优化:
首先,将比较常用的选择项放在前面，使它们可以较快地被匹配;
其次，我们可以尝试提取共用模式，例如，将“(abcd|abef)”替换为“ab(cd|ef)"

5. java序列化:原生序列化

Java提供了一种序列化机制，这种机制能够将一个对象序列化为二进制形式(字节数组)
用于写入磁盘或输出到网络，同时也能从网络或磁盘中读取字节数组，反序列化成对象，在程序中使用

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hVwupQOh-1656732438625)(E:\markdown笔记\java\性能调优.assets\image-20220702105347143.png)]$

6 NIO原理

一种异步非阻塞的I/O模型，也是I/O多路复用的基础，已经被越来越多地应用到大型应用服务器，成为解决高并发与大量连接、I/O处理问题的有效方式底层支撑来自Linux epoll通信模型

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mqrQYqVF-1656732438625)(E:\markdown笔记\java\性能调优.assets\image-20220702105932756.png)]$

6.1 NIO 并发IO场景

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LZyzHWW4-1656732438625)(E:\markdown笔记\java\性能调优.assets\image-20220702110321861.png)]$

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ABwBhEwW-1656732438626)(E:\markdown笔记\java\性能调优.assets\image-20220702110703124.png)]$

6.2 NIO什么情况下不能去用?

数据通信非常频繁不建议,会多出上下文切换.

适合使用NIO的:连接时间长,并发高,通信不是很频繁

7.HashMap的血案与ConcurrentHashMap的正确用法

其他集合案例

HashMap死循环原因一: Map在扩容、多线程Put操作

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6ZmnaAiX-1656732438626)(E:\markdown笔记\java\性能调优.assets\image-20220702111453138.png)]$

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bXcX0H13-1656732438626)(E:\markdown笔记\java\性能调优.assets\image-20220702111510902.png)]$

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QPbHHGds-1656732438626)(E:\markdown笔记\java\性能调优.assets\image-20220702111715993.png)]$

线程安全方案:ConcurrentHashMap

·避免HashMap并发读写脏数据的问题
·JDK 1.7 ConcurrentHashmap分段式锁，性能Synchronized 强太多
·JDK1.8使用Synchronized和CAS、Volatile、红黑树的结合，取代分布式锁

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-y0leDAPn-1656732438627)(E:\markdown笔记\java\性能调优.assets\image-20220702111938984.png)]$

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-N7XsrdNz-1656732438627)(E:\markdown笔记\java\性能调优.assets\image-20220702112206464.png)]$

原网站

版权声明
本文为[呆萌小新@渊洁]所创，转载请带上原文链接，感谢
https://blog.csdn.net/m0_50913327/article/details/125570824