java中string属于什么类型(JDK1.6中String类的坑,快让我裂开了…)
摘要:JVM优化的目标就是:尽可能让对象都在新生代里分配和回收 ,尽量别让太多对象频繁进入老年代 ,避免频繁对老年代进行垃圾回收,同时给系统充足的内存大小 ,避免新生代频繁的进行垃圾回收 。
本文分享自华为云社区《千万不要在生产环境使用这个版本的JDK ,这不?内存又溢出了!快要裂开了!(建议收藏)》 ,作者:冰 河 。
小伙伴的疑问
问题确定
排查问题的整个过程相当耗时 ,这里 ,我就直接说定位到的问题吧 。后面 ,我会单独写一篇详细的排查问题过程的文章!
在排查问题的过程中 ,我发现这位小伙伴使用的JDK还是1.6版本 。开始 ,我也没想那么多 ,继续排查他写的代码,也没找出什么问题 。但是一旦启动生产环境的程序 ,没过多久 ,JVM就抛出了内存溢出的异常 。
这就奇怪了,怎么回事呢?
启动程序时加上合理的JVM参数 ,问题依然存在 。 。 。
没办法 ,继续看他的代码吧!无意间,我发现他写的代码中 ,大量使用了String类的substring()方法来截取字符串。于是 ,我便跟到JDK中的代码查看传递进来的参数 。
这无意间点进来的一次查看 ,竟然找到了问题所在!!
JDK1.6中String类的坑
经过分析 ,竟然发现了JDK1.6中String类的一个大坑!为啥说它是个坑呢?就是因为它的substring()方法会把人坑惨!不多说了 ,我们先来看下JDK1.6中的String类的substring()方法 。
接下来 ,我们来看看JDK1.6中的String类的一个构造方法 ,如下所示。
看到 ,这里 ,相信细心的小伙伴已经发现了问题,导致问题的罪魁祸首就是下面的一行代码 。
在JDK1.6中 ,使用 String 类的构造函数创建子字符串的时候 ,并不只是简单的拷贝所需要的对象,而是每次都会把整个value引用进来 。如果原来的字符串比较大 ,即使这个字符串不再被应用 ,这个字符串所分配的内存也不会被释放。这也是我经过长时间的分析代码得出的结论,确实是太坑了!!
既然问题找到了 ,那我们就要解决这个问题 。
升级JDK
既然JDK1.6中的String类存在如此巨大的坑 ,那最直接有效的方式就是升级JDK 。于是 ,我便跟小伙伴说明了情况 ,让他将JDK升级到JDK1.8 。
同样的 ,我们也来看下JDK1.8中的String类的substring()方法 。
在JDK1.8中的String类的substring()方法中 ,也调用了String类的构造方法来生成子字符串 ,我们来看看这个构造方法 ,如下所示 。
在JDK1.8中 ,当我们需要一个子字符串的时候,substring 生成了一个新的字符串 ,这个字符串通过构造函数的 Arrays.copyOfRange 函数进行构造 。这个是没啥问题 。
优化JVM启动参数
这里 ,为了更好的提升系统的性能,我也帮这位小伙伴优化了JVM启动参数 。
经小伙伴授权 ,我简单列下他们的业务规模和服务器配置:整套系统采用分布式架构 ,架构中的各业务服务采用集群部署,日均访问量上亿 ,日均交易订单50W~100W ,订单系统的各服务器节点配置为4核8G 。目前已将JDK升级到1.8版本。
根据上述条件 ,我给出了JVM调优后的参数配置 。
至于 ,为啥会给出上述JVM参数配置 ,后续我会单独写文章来具体分析如何根据实际业务场景来进行JVM参数调优 。
经过分析和解决问题 ,小伙伴的程序在生产环境下运行的很平稳 ,至少目前还未出现内存溢出的情况!!
结论
如果在程序中创建了比较大的对象 ,并且我们基于这个大对象生成了一些其他的信息 ,此时,一定要释放和这个大对象的引用关系 ,否则 ,就会埋下内存溢出的隐患。
JVM优化的目标就是:尽可能让对象都在新生代里分配和回收,尽量别让太多对象频繁进入老年代 ,避免频繁对老年代进行垃圾回收 ,同时给系统充足的内存大小,避免新生代频繁的进行垃圾回收 。
点击关注 ,第一时间了解华为云新鲜技术~
创心域SEO版权声明:以上内容作者已申请原创保护,未经允许不得转载,侵权必究!授权事宜、对本内容有异议或投诉,敬请联系网站管理员,我们将尽快回复您,谢谢合作!