JDK1.6中String类的坑,快让我裂开了…(jdk8 string)

  本篇文章为你整理了JDK1.6中String类的坑,快让我裂开了…(jdk8 string)的详细内容,包含有jdk9 string jdk8 string 为什么jdk1.7后又可以用string类型作为switch参数呢? java string... JDK1.6中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()方法。

  
if(beginIndex endIndex){

   throw new StringIndexOutOfBoundsException(endIndex - beginIndex);

   return ((beginIndex == 0) (endIndex == count)) ? this : new String(offset + beginIndex, endIndex - beginIndex, value);

  }

 

 

  
看到,这里,相信细心的小伙伴已经发现了问题,导致问题的罪魁祸首就是下面的一行代码。

  
在JDK1.6中,使用 String 类的构造函数创建子字符串的时候,并不只是简单的拷贝所需要的对象,而是每次都会把整个value引用进来。如果原来的字符串比较大,即使这个字符串不再被应用,这个字符串所分配的内存也不会被释放。这也是我经过长时间的分析代码得出的结论,确实是太坑了!!

  既然问题找到了,那我们就要解决这个问题。

  升级JDK

  既然JDK1.6中的String类存在如此巨大的坑,那最直接有效的方式就是升级JDK。于是,我便跟小伙伴说明了情况,让他将JDK升级到JDK1.8。

  同样的,我们也来看下JDK1.8中的String类的substring()方法。

  
return ((beginIndex == 0) (endIndex == value.length)) ? this

   : new String(value, beginIndex, subLen);

  }

 

 

  
在JDK1.8中的String类的substring()方法中,也调用了String类的构造方法来生成子字符串,我们来看看这个构造方法,如下所示。

  
if (offset value.length - count) {

   throw new StringIndexOutOfBoundsException(offset + count);

   this.value = Arrays.copyOfRange(value, offset, offset+count);

  }

 

 

  
在JDK1.8中,当我们需要一个子字符串的时候,substring 生成了一个新的字符串,这个字符串通过构造函数的 Arrays.copyOfRange 函数进行构造。这个是没啥问题。

  优化JVM启动参数

  这里,为了更好的提升系统的性能,我也帮这位小伙伴优化了JVM启动参数。

  经小伙伴授权,我简单列下他们的业务规模和服务器配置:整套系统采用分布式架构,架构中的各业务服务采用集群部署,日均访问量上亿,日均交易订单50W~100W,订单系统的各服务器节点配置为4核8G。目前已将JDK升级到1.8版本。

  根据上述条件,我给出了JVM调优后的参数配置。

  


-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M

 

  
至于,为啥会给出上述JVM参数配置,后续我会单独写文章来具体分析如何根据实际业务场景来进行JVM参数调优。

  经过分析和解决问题,小伙伴的程序在生产环境下运行的很平稳,至少目前还未出现内存溢出的情况!!

  如果在程序中创建了比较大的对象,并且我们基于这个大对象生成了一些其他的信息,此时,一定要释放和这个大对象的引用关系,否则,就会埋下内存溢出的隐患。

  JVM优化的目标就是:尽可能让对象都在新生代里分配和回收,尽量别让太多对象频繁进入老年代,避免频繁对老年代进行垃圾回收,同时给系统充足的内存大小,避免新生代频繁的进行垃圾回收。

  

  点击关注,第一时间了解华为云新鲜技术~

  以上就是JDK1.6中String类的坑,快让我裂开了…(jdk8 string)的详细内容,想要了解更多 JDK1.6中String类的坑,快让我裂开了…的内容,请持续关注盛行IT软件开发工作室。

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: