码迷，mamicode.com
首页 > 其他好文 > 详细

String.split引发的“内存泄露”

时间：2014-09-22 17:17:22      阅读：306      评论：0      收藏：0      [点我收藏+]

标签：blog   http   io   os   使用   java   ar   strong   for   

一直赞叹Sun对待技术的严谨和优雅（bless Sun）。Sun JDK中Java库的源代码，连注释都清清楚楚、规规范范，javadoc注解的使用也一丝不苟，读起来很熟舒服。因此，在日常工作和学习中，经常读读 Java库的源代码，不亦乐乎？如果遇到诡异问题，源代码的帮助就更大了。

闲话少说，回归正题。这几天，一直在为Java的“内存泄露”问题纠结。Java应用程序占用的内存在不断的、有规律的上涨，最终超过了监控阈值。 福尔摩斯不得不出手了！

说起Java的内存泄露，其实定义不是那么明确。首先，如果JVM没有bug，那么理论上是不会出现“无法回收的堆空间”，也就是说C/C++中的 那种内存泄露在Java中不存在的。其次，如果由于Java程序一直持有某个对象的引用，但是从程序逻辑上看，这个对象再也不会被用到了，那么我们可以认 为这个对象被泄露了。如果这样的对象数量很多，那么很明显，大量的内存空间就被泄露（“浪费”更准确一些）了。

不过，本文要说的内存泄露，并不属于上述原因，因此打上了引号。其具体原因，确实出乎意料。欲知详情，请看下面讲解。

分析内存泄露的一般步骤

 

如果发现Java应用程序占用的内存出现了泄露的迹象，那么我们一般采用下面的步骤分析

  1. 把Java应用程序使用的heap dump下来
  2. 使用Java heap分析工具，找出内存占用超出预期（一般是因为数量太多）的嫌疑对象
  3. 必要时，需要分析嫌疑对象和其他对象的引用关系。
  4. 查看程序的源代码，找出嫌疑对象数量过多的原因。

dump heap

如果Java应用程序出现了内存泄露，千万别着急着把应用杀掉，而是要保存现场。如果是互联网应用，可以把流量切到其他服务器。保存现场的目的就是 为了把运行中JVM的heap dump下来。

JDK自带的jmap工具，可以做这件事情。它的执行方法是：

jmap -dump:format=b,file=heap.bin <pid>

format=b的含义是，dump出来的文件时二进制格式。

file-heap.bin的含义是，dump出来的文件名是heap.bin。

<pid>就是JVM的进程号。

（在linux下）先执行ps aux | grep java，找到JVM的pid；然后再执行jmap -dump:format=b,file=heap.bin <pid>，得到heap dump文件。

analyze heap

将二进制的heap dump文件解析成human-readable的信息，自然是需要专业工具的帮助，这里推荐Memory Analyzer 。

Memory Analyzer，简称MAT，是Eclipse基金会的开源项目，由SAP和IBM捐助。巨头公司出品的软件还是很中用的，MAT可以分析包含数亿级对 象的heap、快速计算每个对象占用的内存大小、对象之间的引用关系、自动检测内存泄露的嫌疑对象，功能强大，而且界面友好易用。

MAT的界面基于Eclipse开发，以两种形式发布：Eclipse插件和Eclipe RCP。MAT的分析结果以图片和报表的形式提供，一目了然。总之个人还是非常喜欢这个工具的。下面先贴两张官方的screenshots：

bubuko.com,布布扣

bubuko.com,布布扣 

言归正传，我用MAT打开了heap.bin，很容易看出，char[]的数量出其意料的多，占用90%以上的内存 。一般来说，char[]在JVM确实会占用很多内存，数量也非常多，因为String对象以char[]作为内部存储。但是这次的char[]太贪婪 了，仔细一观察，发现有数万计的char[]，每个都占用数百K的内存 。这个现象说明，Java程序保存了数以万计的大String对象 。结合程序的逻辑，这个是不应该的，肯定在某个地方出了问题。

顺藤摸瓜

在可疑的char[]中，任意挑了一个，使用Path To GC Root功能，找到该char[]的引用路径，发现String对象是被一个HashMap中引用的 。这个也是意料中的事情，Java的内存泄露多半是因为对象被遗留在全局的HashMap中得不到释放。不过，该HashMap被用作一个缓存，设置了缓 存条目的阈值，导达到阈值后会自动淘汰。从这个逻辑分析，应该不会出现内存泄露的。虽然缓存中的String对象已经达到数万计，但仍然没有达到预先设置 的阈值（阈值设置地比较大，因为当时预估String对象都比较小）。

但是，另一个问题引起了我的注意：为什么缓存的String对象如此巨大？内部char[]的长度达数百K。虽然缓存中的String对象数 量还没有达到阈值，但是String对象大小远远超出了我们的预期，最终导致内存被大量消耗，形成内存泄露的迹象（准确说应该是内存消耗过多） 。

就这个问题进一步顺藤摸瓜，看看String大对象是如何被放到HashMap中的。通过查看程序的源代码，我发现，确实有String大对象，不 过并没有把String大对象放到HashMap中，而是把String大对象进行split（调用String.split方法），然后将split出 来的String小对象放到HashMap中 了。

这就奇怪了，放到HashMap中明明是split之后的String小对象，怎么会占用那么大空间呢？难道是String类的split方法有问 题？

查看代码

带着上述疑问，我查阅了Sun JDK6中String类的代码，主要是是split方法的实现：

 

[java] view plaincopy
 
  1. public   
  2. String[] split(String regex, int limit) {  
  3.     return Pattern.compile(regex).split(this, limit);  
  4. }  

 

可以看出，Stirng.split方法调用了Pattern.split方法。继续看Pattern.split方法的代码：

 

[java] view plaincopy
 
  1. public   
  2. String[] split(CharSequence input, int limit) {  
  3.         int index = 0;  
  4.         boolean matchLimited = limit > 0;  
  5.         ArrayList<String> matchList = new   
  6. ArrayList<String>();  
  7.         Matcher m = matcher(input);  
  8.         // Add segments before each match found  
  9.         while(m.find()) {  
  10.             if (!matchLimited || matchList.size() < limit - 1) {  
  11.                 String match = input.subSequence(index,   
  12. m.start()).toString();  
  13.                 matchList.add(match);  
  14.                 index = m.end();  
  15.             } else if (matchList.size() == limit - 1) { // last one  
  16.                 String match = input.subSequence(index,  
  17.                                                    
  18. input.length()).toString();  
  19.                 matchList.add(match);  
  20.                 index = m.end();  
  21.             }  
  22.         }  
  23.         // If no match was found, return this  
  24.         if (index == 0)  
  25.             return new String[] {input.toString()};  
  26.         // Add remaining segment  
  27.         if (!matchLimited || matchList.size() < limit)  
  28.             matchList.add(input.subSequence(index,   
  29. input.length()).toString());  
  30.         // Construct result  
  31.         int resultSize = matchList.size();  
  32.         if (limit == 0)  
  33.             while (resultSize > 0 &&   
  34. matchList.get(resultSize-1).equals(""))  
  35.                 resultSize--;  
  36.         String[] result = new String[resultSize];  
  37.         return matchList.subList(0, resultSize).toArray(result);  
  38.     }  

 

注意看第11行：Stirng match = input.subSequence(intdex, m.start()).toString();

这里的match就是split出来的String小对象，它其实是String大对象subSequence的结果。继续看 String.subSequence的代码：

 

[java] view plaincopy
 
  1. public   
  2. CharSequence subSequence(int beginIndex, int endIndex) {  
  3.         return this.substring(beginIndex, endIndex);  
  4. }  

 

String.subSequence有调用了String.subString，继续看：

 

[java] view plaincopy
 
  1. public String   
  2. substring(int beginIndex, int endIndex) {  
  3.     if (beginIndex < 0) {  
  4.         throw new StringIndexOutOfBoundsException(beginIndex);  
  5.     }  
  6.     if (endIndex > count) {  
  7.         throw new StringIndexOutOfBoundsException(endIndex);  
  8.     }  
  9.     if (beginIndex > endIndex) {  
  10.         throw new StringIndexOutOfBoundsException(endIndex - beginIndex);  
  11.     }  
  12.     return ((beginIndex == 0) && (endIndex == count)) ? this :  
  13.         new String(offset + beginIndex, endIndex - beginIndex, value);  
  14.     }  

 

看第12、13行，我们终于看出眉目，如果subString的内容就是完整的原字符串，那么返回原String对象；否则，就会创建一个新的 String对象，但是这个String对象貌似使用了原String对象的char[]。我们通过String的构造函数确认这一点：

 

[java] view plaincopy
 
  1. // Package   
  2. private constructor which shares value array for speed.  
  3.     String(int offset, int count, char value[]) {  
  4.     this.value = value;  
  5.     this.offset = offset;  
  6.     this.count = count;  
  7.     }  

 

为了避免内存拷贝、加快速度，Sun JDK直接复用了原String对象的char[]，偏移量和长度来标识不同的字符串内容。也就是说，subString 出的来String小对象仍然会指向原String大对象的char[]，split也是同样的情况 。这就解释了，为什么HashMap中String对象的char[]都那么大。

原因解释

其实上一节已经分析出了原因，这一节再整理一下：

  1. 程序从每个请求中得到一个String大对象，该对象内部char[]的长度达数百K。
  2. 程序对String大对象做split，将split得到的String小对象放到HashMap中，用作缓存。
  3. Sun JDK6对String.split方法做了优化，split出来的Stirng对象直接使用原String对象的char[]
  4. HashMap中的每个String对象其实都指向了一个巨大的char[]
  5. HashMap的上限是万级的，因此被缓存的Sting对象的总大小=万*百K=G级。
  6. G级的内存被缓存占用了，大量的内存被浪费，造成内存泄露的迹象。

解决方案

原因找到了，解决方案也就有了。split是要用的，但是我们不要把split出来的String对象直接放到HashMap中，而是调用一下 String的拷贝构造函数String(String original)，这个构造函数是安全的，具体可以看代码：

 

[java] view plaincopy
 
  1.     /** 
  2.      * Initializes a newly created {@code String} object so that it  
  3. represents 
  4.      * the same sequence of characters as the argument; in other words,  
  5. the 
  6.      * newly created string is a copy of the argument string. Unless an 
  7.      * explicit copy of {@code original} is needed, use of this  
  8. constructor is 
  9.      * unnecessary since Strings are immutable. 
  10.      * 
  11.      * @param  original 
  12.      *         A {@code String} 
  13.      */  
  14.     public String(String original) {  
  15.     int size = original.count;  
  16.     char[] originalValue = original.value;  
  17.     char[] v;  
  18.     if (originalValue.length > size) {  
  19.         // The array representing the String is bigger than the new  
  20.         // String itself.  Perhaps this constructor is being called  
  21.         // in order to trim the baggage, so make a copy of the array.  
  22.             int off = original.offset;  
  23.             v = Arrays.copyOfRange(originalValue, off, off+size);  
  24.     } else {  
  25.         // The array representing the String is the same  
  26.         // size as the String, so no point in making a copy.  
  27.         v = originalValue;  
  28.     }  
  29.     this.offset = 0;  
  30.     this.count = size;  
  31.     this.value = v;  
  32.     }  

 

只是，new String(string)的代码很怪异，囧。或许，subString和split应该提供一个选项，让程序员控制是否复用String对象的 char[]。

是否是Bug

 

虽然，subString和split的实现造成了现在的问题，但是这能否算String类的bug呢？个人觉得不好说。因为这样的优化是比较合理 的，subString和spit的结果肯定是原字符串的连续子序列。只能说，String不仅仅是一个核心类，它对于JVM来说是与原始类型同等重要的 类型。

JDK实现对String做各种可能的优化都是可以理解的。但是优化带来了忧患，我们程序员足够了解他们，才能用好他们。

String.split引发的“内存泄露”

标签：blog   http   io   os   使用   java   ar   strong   for   

原文地址：http://www.cnblogs.com/chenqiushi/p/3985852.html
踩
(0)
赞
(0)
   
举报
评论 一句话评论（0）
登录后才能评论！
分享档案
更多>
2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)
周排行
mamicode.com排行更多图片
更多
友情链接
兰亭集智   国之画   百度统计   站长统计   阿里云   chrome插件   新版天听网
关于我们 - 联系我们 - 留言反馈
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码！