内存数据优化策略

      我们能做点什么呢？　　
　　“这很好，但是我们没有任何选择除了使用String和其它Java提供的类型，是不是这样呢？”我听到你们再问，那么让我们来找找答案吧。

　 封装类
　　
　　封装类比如java.lang.Integer，看起来保存大量的数据在内存 中像一个坏的选择。假如你尽力为了内存的经济，那么就要避免这么做。使用你自己的针对int的向量类并不难。当然，假如Java的核心函数库已经包含了这 个那就最好不过了。或许这种情况在Java拥有非凡类型的时候将会大大改观。
　　
　 多位数组
　　
　 　对于使用多维数组的大型的数据结构，你可以时常的通过简单的索引变换减少额外的维数/例如：转换int[dim1][dim2]的实例到一个 int[dim1*dim2]的实例，改变所有形如a[i][j]的表达式为a[i*dim1+j]。这样你就不必花功夫在dim1上的索引检查可以提高 效率。
　　
    java.lang.String
　　
　　你可以使用一些小技巧去减少你的应用中字符串的静态内存大小。
　　
　 　首先，你可以尝试一种很平常的技术，就是当一个应用从一个数据文件或者网络连接中载入或者缓存很多的字符串，并且这种字符串的值是有限变化的。举个例 子：假如你想分析一个XML文件，在这个文件中，你经常碰到某种属性，但是这个属性仅仅被限制在两个可能的值。你的目标：通过一个散列映射过滤所有的字符 串，减少所有相同的但是明显字符串和目标对象引用一样的。

public String internString (String s) {
　　if (s == null) return null;
　　     String is = (String) m_strings.get (s);
　　if (is != null)
　　     return is;
　　else {
　　     m_strings.put (s, s);
　　     return s;
　　}
}
　　
private Map m_strings = new HashMap ();

 假如适用成功，这个技巧能够成倍的减少你的静态内存需求。一个富有经验的读者应该能够观察到这个技巧复制 java.lang.String.intern()的功能性。有无数的理由存在来让你避免使用String.intern()方法。其中一个就是现在的 JVM几乎没有能实现大量数据的保留。
　　
　　假如你的字符串是完全不同的，会发生什么情况呢？这就是要介绍的第二个技巧，重新收集那些 小的字符串空间，这些空间潜在的隐藏于char数组中，因为使用数组大概只占了字符串封装所占用的内存的一半。因此，当我们的应用缓存许多独特的字符传 值，我们仅仅只要保持在内存中的数组，在需要的时候转换为字符串。假如这个字符串只是作为暂时的，很快就会抛弃，这将很有效果。一个简单的实验就是从一个 字典文件中选出作为缓存的90000个单词，这些数据大约5.6M的大小，假如是char的话，只需要3.4M的空间，只占用了以前的65%。
　　
　 　第二个技巧明显的包含一个不利条件，就是你不能支持通过一个构造函数转换一个char[]成为字符串，因为这个构造函数没有复制这个数组而将拥有这个数 组。为什么呢？因为这个完全的public的字符串API确保每一个字符串是不可变的，所以每个字符串的构造函数显然要复制输入的数据然后传入它的参数。
　　
　 　然后，我们将使用第三个技巧。这个技巧用在当转换一个char数组为一个字符串的代价证实太高的时候。该技巧使用 java.lang.String.substr()的功能避免数据复制：这个方法的是显示用了字符串的不变性，并且创建的一个影子字符串对象来共享字符 内容，但是它的内部的开始位置和结束位置都是正确的。我们还是写一个例子，new String(“smiles”).substring(1,5)是一个字符串，这个字符串是字符缓冲从位置1到位置4的字符结束，并且这个字符缓冲将共 享原来的字符串构造函数指向的字符缓冲。你可以象一下这样使用：给出一个大的字符串集合，你可以合并它的字符内容到一个大的字符数组，在它之上创建一个字 符串，并且使用这个主串的子串来重新创建一个原来的字符串。如以下描述：

public static String [] compactStrings (String [] strings) {
　　String [] result = new String [strings.length];
　　int offset = 0;
　　for (int i = 0; i < strings.length; ++ i)
　　offset += strings [i].length ();
　　// Can't use StringBuffer due to how it manages capacity
　　char [] allchars = new char [offset];
　　offset = 0;
　　for (int i = 0; i < strings.length; ++ i) {
　　     strings [i].getChars (0, strings [i].length (), allchars, offset);
　　     offset += strings [i].length ();
　　}
　　String allstrings = new String (allchars);
　　offset = 0;
　　for (int i = 0; i < strings.length; ++ i)
　　result [i] = allstrings.substring (offset,
　　　　 offset += strings [i].length ());
　　return result;
}

     以上方法返回一个新的字符串集等同于输入的字符串集，但是在内存中更加得紧凑。重新获得每个字符串数组的16个字节的头部，在方法中被有效的移除。这个存 储在缓存压缩大多数短的字符串时比较有效果。当这个方法用于同样的90000个单词的字典时，内存从5.6M节约到4.2M，大概节约了30%。
　　
     这些努力是否值得呢？
　 　我这里提到的方法看起来都是很细微的优化，是否值得花时间去实现呢？但是，记住我们脑子里面应该记住：服务端的应用程序能够缓存大量的数据在内存中的话 讲能够大大的提高从磁盘和数据库提取数据的性能和效率。在当前32位的JVM中，几百兆的缓存数据代表堆中很引人注重的位置。减少30%或者更多不应该被 嘲笑，它能将系统的可测性质中能提高很显著的水平。当然这些技巧不适用于一开始就很好设计的数据结构，事实的决定要由hotspots来决定。无论如何， 你现在应该更加了解你的对象消耗了多少内存。
　　
　　关于作者：
　　Vladimir RouBTsov拥有超过12年的多种语言的编程经验，其中包括从1995年就开始用得Java。目前，它作为资深开发者在Austin, Texas.为Trilogy开发企业级软件。平时的业余爱好就是开发一些关于Java字节代码或源程序代码的工具。