性能文章>小心!用String写代码可能会内存泄漏!>

小心!用String写代码可能会内存泄漏!转载

2年前
336815

文章来源:石杉的架构笔记原创文章



目录

  • String 字符串在内存里是如何存储的?

  • String.intern() 方法

  • String 字符串是如何引发内存泄漏呢?

  • 总结

 

今天给大家聊聊咱们平时写代码的时候,最常见的 String 字符串代码,他的一些底层原理,以及使用不当可能引发的内存泄漏的问题,相信对于大家平时日常开发写代码会有一定的帮助。

 

String 字符串在内存里是如何存储的?

 

首先呢,当我们平时在代码中写下一行 String 类型的代码时,大家知道这个 String 字符串在内存里是如何存储的吗?

 

比如这样的一行代码:String username = "zhangsan",这个"zhangsan"其实就是一串字符串,实际上他在底层是用一个数组来存放的,而且这个数组大小就严格等于这个字符串的长度,他是不可变的。

 

如下图:

接着呢,对于 Java 中的字符串来说,有一个常量池的概念,意思就是说,对于相同的字符串内容,他往往会在内存里用同一个数组来表示,而不会对相同的字符串内容创建出不同的数组来存放。

 

比如说下面两行代码,大家看看:
String username = "zhangsan"
String nickname = "zhangsan";

 

上面的 username 和 nickname 他们两个字符串指向的内容都是"zhangsan",实际上在底层都是用同一个数组来存放的。

 

如下图所示:

所以说,正是因为相同的字符串是引用的同一个底层的数组,所以如果用类似于 System.out.println(username == nickname) 这种判断代码的话,会发现 username == nickname 返回的是 true,因为他们俩就是指向了底层同一个数组的。

 

另外再给大家普及一个字符串的知识点,那就是如果我们用一个字符串创建一个 String 对象的话,那他在内存里一定是另外的一个对象了。

 

如下代码所示,大家看看:
String username = "zhangsan"
String nickname = new String("zhangsan"); 
System.out.println(username == nickname);

 

大家看上面代码,此时 username 和 nickname 比较还是返回 true 吗?

 

那不可能的,此时一定是 false,因为此时在内存里,username 是指向一个数组的,但是 nickname 是指向一个 String 对象的,只不过这个 String 对象里面是有一个"zhangsan"字符串而已。

 

如下图:

但是这个时候又给大家再次介绍一个知识点了,那就是这个 String 对象内部的"zhangsan"字符串,是怎么存储的呢?

 

其实啊,这个 String 对象内部的"zhangsan"字符串还是引用了之前的那个数组的,如下图所示:

String.intern() 方法

 

所以说,如果此时你用 String.intern() 方法,就会发现你可以拿到 String 对象里的"zhangsan"字符串,此时再用这个字符串做比较,还是返回的是 true。

 

大家看下面代码就懂了:
String username = "zhangsan"
String nickname = new String("zhangsan");
System.out.println(username == nickname.intern()); // 返回的是true

 

String 字符串是如何引发内存泄漏呢?

 

好,那么大家都理解了 Java 里字符串的基本原理后,我们就可以来给大家讲讲平时我们用字符串 String 写代码,一旦要是不注意,是如何引发内存泄漏问题的。

 

这个问题主要是出现在 Java 6 以及之前的版本里,在这个较为旧的 Java 版本中,String.substring() 这种字符串截取动作,是会导致内存泄漏的,什么意思呢,我们来看看。

 

在 Java 6 以前的版本中,当你调用 String.substring() 进行字符串截取的时候,他在底层的运作模式是这样的,他会把你的原字符串的数组直接拷贝一份过来,然后用一个 offset 指针和 count 标记,来表名截取后的字符串你是需要哪些。

 

如下图所示:

可是在这种运作模式下就有一个问题了,就是你每次 substring 都会把原数组拷贝一份,可是对于你的子字符串来说仅仅是需要里面的一部分而已,而你缺把原字符串每次都拷贝一份,导致了子字符串中不需要的那部分拷贝内容都是浪费掉的。

 

如下图红圈部分都是子字符串不需要的:

所以此时子字符串不需要的红圈部分处的内容还依然占据了内存,这属于什么问题呢?

 

就是典型的内存泄漏了,也就是说,你要是大量的进行 substring 一类的操作,就可能会大量的拷贝字符串数组,然后很多拷贝后的字符串数组里,很多内容都是不需要用的,结果还占据了很多内存空间,这就叫做内存泄漏。

 

内存泄漏指的就是你很多内存空间被占用了,结果你又不用他,别人也没法用,就是典型的占着茅坑不拉屎的行为。

 

所以后来在 Java 7 版本开始就对 String.substring() 进行了源码重构,开始改造了这部分的实现,每次你执行 String.substring,他是把原字符串数组中你需要的那部分拷贝过来就可以了,就避免了每次都重复的拷贝原字符串数组。

 

如下图:

总结

 

在这种 Java 7 以及往后的新版本中,就彻底的解决了 substring 导致的内存泄漏问题了,因此大家平时在用字符串做开发的过程中,也一定要小心谨慎,避免误用老版本的 Java 触发这种内存泄漏隐患。

 

当然现在一般都是用 Java 8 以上的版本,尤其较多的是用 Java 9、Java 10 甚至 Java 11 这几个新版本了。

 

但是不排除有一些公司的非常老旧的系统在维护的时候,用的还是曾经很风靡的 Java 6 这个版本,大家在对这类老系统维护的时候,一定要谨慎注意 substring 内存泄漏问题。

 

若有收获,就点个赞吧!

文章来源:微信公众号

原文链接:https://mp.weixin.qq.com/s/EAqZwSv4hLWbe0IuJc2lwg

点赞收藏
嘿小黑
请先登录,查看1条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

JDBC PreparedStatement 字段值为null导致TBase带宽飙升的案例分析

JDBC PreparedStatement 字段值为null导致TBase带宽飙升的案例分析

随机一门技术分享之Netty

随机一门技术分享之Netty

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

5
1