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

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

1月前
231802

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



目录

  • 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

请先登录,再评论

暂无回复,快来写下第一个回复吧~

为你推荐

关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
谨防JDK8重复类定义造成的内存泄漏
概述 如今JDK8成了主流,大家都紧锣密鼓地进行着升级,享受着JDK8带来的各种便利,然而有时候升级并没有那么顺利?比如说今天要说的这个问题。我们都知道JDK8在内存模型上最大的改变是,放弃了Perm
JVM菜鸟进阶高手之路九(解惑)
关于MAT工具相关知识解惑MAT 不是一个万能工具,它并不能处理所有类型的堆存储文件。但是比较主流的厂家和格式,例如 Sun, HP, SAP 所采用的 HPROF 二进制堆存储文件,以及 IBM 的
JVM垃圾回收与一次线上内存泄露问题分析和解决过程
本文转载自:花椒技术微信公众号 前言内存泄漏(Memory Leak)是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果。Ja
强如 Disruptor 也发生内存溢出?
前言```OutOfMemoryError ```问题相信很多朋友都遇到过,相对于常见的业务异常(数组越界、空指针等)来说这类问题是很难定位和解决的。本文以最近碰到的一次线上内存溢出的定位、解决问题的
spring boot 引起的 “堆外内存泄漏”
背景组内一个项目最近一直报swap区域使用过高异常,笔者被叫去帮忙查看原因。发现配置的4G堆内内存,但是实际使用的物理内存高达7G,确实有点不正常,JVM参数配置是:```java-XX:Metasp
实战:一次疑似内存泄漏的问题排查
问题背景最近服务器到期等因素,进行了迁移。租了其它的外国厂商,但是由于资费问题,购买了1.5G 内存的服务器(现)。因为原本用惯了4G内存的服务器(原),现在压缩成这样,似乎不太能支持我的使用,囧!现
记录一次Flink作业异常的排查过程
最近2周开始接手apache flink全链路监控数据的作业,包括指标统计,业务规则匹配等逻辑,计算结果实时写入elasticsearch. 昨天遇到生产环境有作业无法正常重启的问题,我负责对这个问题