标签:style http io os 使用 java ar strong for
笔主前言:
众所周知,String是Java的JDK中最重要的基础类之一,在笔主心中的地位已经等同于int、boolean等基础数据类型,是超越了一般Object引用类型的高端大气上档次的存在。
但是稍有研究的人就会发现,String对象是不可修改的,源代码中的String类被定义为final,即为终态,不可继承,String也不提供任何直接修改对象内部值的方法,每次使用replace、substring、trim等方法,或是使用字符串连接符+时,都是返回一个全新的String对象,整个String对象的值只能通过构造函数,在初始化对象实例时一次性输入(当然Java语法允许直接使用双引号方式快捷获取String对象实例)。
如果需要动态修改、构造字符串,则需要通过StringBuilder或StringBuffer对象进行操作,并在最终输出时通过toString()、substring()等方法得到String对象。直接使用String对象进行连接、增删替换字符等操作,将不可避免地产生大量临时String对象,影响CPU效率和增加资源回收负担。
今天偶然看到一个外文文章,较为完整详细客观科学的论述了String类被如此设计成不可变结构的原因,下面笔主结合自己的理解,尽量通过浅显的语言意译成中文,科普一下知识。
原文链接:http://www.programcreek.com/2013/04/why-string-is-immutable-in-java/
要解释String被设计成不可变结构的原因,需要从存储空间、同步性、数据类型等方面去分析。
Java语法设计中专门针对String类型,提供了一个特殊的存储机制,叫字符串保留池String intern pool,简单点说,这个池是在内存堆中专门划分一块空间,用来保存所有String对象数据,当程序猿构造一个新字符串String对象时,Java编译机制会优先在这个池子里查找是否已经存在能满足需要的String对象,如果有的话就直接返回该对象的地址引用(没有的话就正常的构造一个新对象,丢进去存起来),因此实际上构造两三个乃至成千上万个同一句话的String对象,得到的是同一个对象引用,这能避免很多不必要的空间开销。
然而如果String对象本身允许被二次修改值内容的话,其中一个引用对String对象的修改将不可避免地影响其他正在引用该对象的变量,诱发出不可预测的后果。
* 上面所说的机制,仅适用于使用以下语法构造String对象的场景:
String string1 = "abcd"; String string2 = "abcd"; // string1 == string2String string1 = new String("abcd"); String string2 = new String("abcd"); // string1 != string2
在HashMap等需要使用hashCode作为键值存储地址的数据结构中,String对象常常作为这些数据结构的key值,常见地组合成如 HashMap<String, Object> 等类型的哈希表结构使用。
当HashMap需要随机调取某个元素的时候(例如 hashMap.get("money"); ),HashMap将调用作为key值的String对象的hashCode()方法,获取能代表这个对象的唯一数值hashCode,定位这个键值对的实际存储地址,继而可以像数组一样通过array[index]这样的下标方式直接访问到目标元素。
由于String类型具备不可变的特性,因此在String对象内的hashCode()方法实际上只需执行一次计算过程,计算后把结果缓存到一个内部私有变量 int hash 中,而后每次需要调用这个String对象的hashCode()方法时,仅仅需要把上次的计算结果hash返回去即可,在物理上强效地保证了这个结果的绝对正确性,当HashMap需要频繁的读取访问任意一组键值对的时候,能节省非常多的CPU计算开销。
* 这一部分看得不是很懂,就笔主的浅显理解不能十分认同原文中的这个解释理由,这一块将按原文翻译与笔主的理解观点同步展示说明。
先展示一段不太真实的代码:
HashSet<String> set = new HashSet<String>(); set.add(new String("a")); set.add(new String("b")); set.add(new String("c")); for(String a: set) a.value = "a";
原文:在这个例子中,如果String是可变的,那么当它的值发生改变时将违反Set的设计(Set只能存储相互唯一的元素)。这个代码案例仅为简单的目的而设计,实际上String类不存在value变量。
按笔主理解解释:
在这段代码中,三个String对象依次使用HashSet的add()方法合法地添加到了set对象中。
此时如果String是内容可变的话,那么通过后面的for循环中 a.value = "a"; 这一句伪代码,set对象中的三个成员变量都将变成String("a"),依据解释1所提到的String Pool的情况,这三个对象有可能会变成指向同一个字符串String对象"a",即set内部存了三个相同的对象,而这种情况违背了Set类型的元素唯一性设计定义——Set中存储的对象必需相互独立唯一,不能重复。
退一步讲,即使这三个对象依然是三个相互独立的String对象"a",而根据String类设计的hashCode()算法,这三个独立的String对象依然计算出了相同的hashCode值,显然也是违反了HashSet的设计——三个对象同时指向了相同的存储地址。
任何一种情况都将在Set对象的外部不可控地违反了Set或HashSet本身设计的规定,诱发出不可预测的后果,而在语法检测上却毫无问题地通过了。
* 之所以说 a.value = "a"; 是伪代码,并非因为原文所说String类不存在value变量,而是因为String类内的私有变量 private final char value[] 是不允许外部操作的,另外在数组语法上也不允许按这种方式赋值,String中的value数组确实存储的就是初始化传入的字符串各字符数据,同时也是String计算hashCode算法的唯一依据。
** 如果严格定义String是内容可变这一前提,那么解释1中提出的String Pool将无法实现,也就是说调用三次构造函数,必然返回三个互相独立的对象,因此此例严格说并不会违反Set的元素唯一性定义,但依然会出现后面的相同hashCode值问题。
*** 一般而言,不同的对象通过hashCode()方法将得到不同且唯一的hashCode值,但由于这里假想的可变String内容被更换,而导致不同的String对象产生相同hashCode值,在HashSet/HashMap中将产生异常表现,在本文最后的补充环节,笔主将使用一小段代码进行模拟演示。
String被广泛用于网络连接、文件IO等多种Java基础类的参数中,如果String内容可变的话,将潜在地带来多种严重安全隐患,例如链接地址被暗中更改等,出于同样的原因,在Java反射机制中可变String参数也会导致潜在的安全威胁。
例如以下网络连接代码示例(修改自原文):
boolean connect(string url){ // 验证url地址是否安全,不安全的网络访问将被异常抛出阻止 if (!isSecure(url)) { throw new SecurityException(); } // 上一步url已通过安全检验,但如果url在这里能够被(其他线程)其他引用修改,将触发严重的安全威胁 mayCauseProblemWhileOpen(url); }
由于不可变对象内容不可能被修改,因此能在多线程中被任意自由访问而不会导致任何线程安全问题,同时也就不需要再做任何多余的同步操作开销。
总的来说,String的不可变特性设计就是出于效率和安全性的考虑,这也是其他类一般情况下更倾向于被设计成不可变特性的原因。
在这里,笔主主要想讨论在解释3的***中提到的可变String对象产生相同hashCode值在HashMap中的异常表现问题。
先说明一个前提,String类中的hashCode()方法经过改写,与Object中的hashCode()不同,String中的hashCode()计算的唯一依据是String对象本身的字符串内容,如果存在两个内容同为"Monkey"的String对象,这两个对象经过hashCode()计算出的hashCode值将完全相同,被HashMap视为同一个key对象。
可变String模拟类:
package test; /** * 可变字符串模拟类 * * @since 2014-6-21 下午6:14:16 * @author Wavky.Wand */ public class ModifiableString { private String mContent; public ModifiableString(String content) { mContent = content; } /** * 更变字符串内容 * * @param mContent * the content to set */ public void setContent(String mContent) { this.mContent = mContent; } @Override public int hashCode() { return mContent.hashCode(); } /** * 依据Java类设计规则与HashMap需求,同时改写equals()方法,当两个对象hashCode相同时,equals()方法判断两个对象为相同 */ @Override public boolean equals(Object obj) { return obj.hashCode() == mContent.hashCode(); } }
测试类:
package test; import java.util.HashMap; /** * * @since 2014-2-2 下午4:16:12 * @author Wavky.Wand */ public class Test { public static void main(String[] args) { ModifiableString m1 = new ModifiableString("123"); ModifiableString m2 = new ModifiableString("456"); ModifiableString m3 = new ModifiableString("789"); // 输出三个对象的hashCode out("m1 hashCode:" + m1.hashCode()); // 48690 out("m2 hashCode:" + m2.hashCode()); // 51669 out("m3 hashCode:" + m3.hashCode()); // 54648 // 初始化HashMap HashMap<ModifiableString, String> map = new HashMap<ModifiableString, String>(); map.put(m1, "A"); map.put(m2, "B"); map.put(m3, "C"); // 输出初始化完毕后的HashMap out("初始化完毕的HashMap"); out("map size:" + map.size()); // 3 out("map.get(m1):" + map.get(m1)); // A out("map.get(m2):" + map.get(m2)); // B out("map.get(m3):" + map.get(m3)); // C out("迭代输出HashMap的所有key值"); for (ModifiableString m : map.keySet()) { out(m); // @c9d5 @be32 @d578 } out("迭代输出HashMap的所有key对应的value值"); for (ModifiableString m : map.keySet()) { out(map.get(m)); // A B C 三个value值依次正常输出 } out("迭代输出HashMap的所有value值"); for (String s : map.values()) { out(s); // A B C 三个value值依次正常输出 } // 更改m3的内容,与m1内容相同 out("m3.setContent(123)"); m3.setContent("123"); // 输出更改m3内容后的信息 out("m1 hashCode:" + m1.hashCode()); // 48690 out("m2 hashCode:" + m2.hashCode()); // 51669 out("m3 hashCode:" + m3.hashCode()); // 48690 out("m1==m3:" + (m1 == m3)); // false out("m1.equals(m3):" + m1.equals(m3)); // true out("重设m3内容后的HashMap"); out("map size:" + map.size()); // 3 out("map.get(m1):" + map.get(m1)); // A out("map.get(m2):" + map.get(m2)); // B // 因为m3内容与m1一致,hashCode与equal方法判断m3与m1相等,因此HashMap返回m1的内容, // 而m3对应的value值C无法再通过key获取,类似于内存泄露状态 out("map.get(m3):" + map.get(m3)); // A out("迭代输出HashMap的所有key值"); for (ModifiableString m : map.keySet()) { out(m); // @be32 @c9d5 @be32 实际为16进制无符号hashCode值,第一个与第三个相同 } out("迭代输出HashMap的所有key对应的value值"); for (ModifiableString m : map.keySet()) { out(map.get(m)); // A B A 无法通过任何一个key获取到第三个value值C } out("迭代输出HashMap的所有value值"); for (String s : map.values()) { out(s); // A B C 三个value值依次正常输出 } // 移除HashMap中的m3键值对 out("map.remove(m3)"); map.remove(m3); // 输出更改m3内容后的信息 out("删除m3内容后的HashMap"); out("map size:" + map.size()); // 2 HashMap内剩余两条键值对 out("map.get(m1):" + map.get(m1)); // null 通过m1获取value,无返回 out("map.get(m2):" + map.get(m2)); // B out("map.get(m3):" + map.get(m3)); // null 通过m3获取value,无返回 out("迭代输出HashMap的所有key值"); for (ModifiableString m : map.keySet()) { out(m); // @c9d5 @be32 m1或m3其中一个key被移除 } out("迭代输出HashMap的所有key对应的value值"); for (ModifiableString m : map.keySet()) { out(map.get(m)); // B null 无法通过任何一个key获取到原第三个value值C } out("迭代输出HashMap的所有value值"); for (String s : map.values()) { out(s); // B C 显示实际上第一个键值对被删除,而最后一个未被删除,但无法获取到 } } static void out(Object o) { System.out.println(o); } }
分析:
在这个略显冗长的测试类中,分别执行了三个主要步骤:
1、使用三个独立的ModifiableString对象(分别为m1:123->A, m2:456->B, m3:789->C)初始化一个HashMap表对象,第一轮的HashMap信息输出显示,三个对象均被正常添加到map表中,并能分别通过三个key(m1/m2/m3)读取对应的value值(A/B/C)。
2、更改第三个key对象m3的内容为123(与第一个key对象m1相同),输出信息显示三个key依然为相互独立的对象,但m3的hashCode值变成与m1的一样,第二轮HashMap信息输出显示,HashMap依然持有三个键值对,通过m3作为key获取到的value值为m1对应的value值A,而m3本来对应的value值C却无法再通过keySet()方法返回的任何一个key获取得到。
3、删除第三个key对象m3,第三轮HashMap信息输出显示,HashMap持有的键值对剩下两个,分别是m2的key和m1或m3的key(由于hashCode一样,无法区别),其中只有m2对应的value B能正常获取到,而通过迭代value显示出HashMap内被删除的是第一个key对象m1对应的键值对,而非m3对应的,但m3对应的value值C依旧无法通过keySet()方法返回的任何一个key获取得到。
通过三个步骤的HashMap内部结构解析图可以看到,HashMap中的每个键值对依然持有各自独立的key对象,但是在后面的两步骤中,第三个键值对一直处于异常状态,无法正常的通过key对象获取。
在深入HashMap的源代码中,逐步跟踪put(K key, V value)->addEntry(int hash, K key, V value, int bucketIndex)->createEntry(int hash, K key, V value, int bucketIndex)方法可以发现,在数据初始化过程中,三个对象通过HashMap的put()方法,最终被存放在一个内部键值数组Entry<K,V>[] table中,存放的位置正好是这个对象的hashCode值代表的下标位置,同样跟踪get(Object key)->getEntry(Object key)方法可以发现,使用key对象通过get()方法,最终获取到的是HashMap中的table数组中,这个key的hashCode值代表的下标位置存储的value值。
而上面的第二步骤通过人为方式强制改变了第三个key对象m3的hashCode值,自然就丢失了获取m3对应的value的索引了,因为整个数据更改过程并没有通知到HashMap更新原本m3对应的value在table数组中的存储位置,所以实际上从第二步骤开始,整个HashMap的内部数据就已经处于一种非同步的异常状态,无法继续正常工作了。
结论:
从这个实验中可以看出,HashMap并不支持key对象的hashCode发生动态变化,不可变对象是作为HashMap的key的最优选择。
另外也从侧面反映出了String的不可变特性在解释2与解释3中发挥出的重要作用。
标签:style http io os 使用 java ar strong for
原文地址:http://my.oschina.net/gagabear/blog/317261