__2017-12-16 如一模式识别研究

如一模式识别研究

JAVA>>【翻译】为什么Java中的String不可变

转自:http://www.cnblogs.com/wavky/p/why-string-is-immutable-in-java.html

笔主前言:

众所周知,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/

为什么Java中的String是不可变的?

要解释String被设计成不可变结构的原因,需要从存储空间、同步性、数据类型等方面去分析。

解释1:满足 String Pool (String intern pool) 字符串保留池的需要

Java语法设计中专门针对String类型,提供了一个特殊的存储机制,叫字符串保留池String intern pool,简单点说,这个池是在内存堆中专门划分一块空间,用来保存所有String对象数据,当程序猿构造一个新字符串String对象时,Java编译机制会优先在这个池子里查找是否已经存在能满足需要的String对象,如果有的话就直接返回该对象的地址引用(没有的话就正常的构造一个新对象,丢进去存起来),因此实际上构造两三个乃至成千上万个同一句话的String对象,得到的是同一个对象引用,这能避免很多不必要的空间开销。

然而如果String对象本身允许被二次修改值内容的话,其中一个引用对String对象的修改将不可避免地影响其他正在引用该对象的变量,诱发出不可预测的后果。

* 上面所说的机制,仅适用于使用以下语法构造String对象的场景:

String string1 = "abcd";

String string2 = "abcd"; // string1 == string2

String string1 = new String("abcd");

String string2 = new String("abcd"); // string1 != string2

解释2:缓存Hashcode的需要

在HashMap等需要使用hashCode作为键值存储地址的数据结构中,String对象常常作为这些数据结构的key值,常见地组合成如 HashMap 等类型的哈希表结构使用。

当HashMap需要随机调取某个元素的时候(例如 hashMap.get("money"); ),HashMap将调用作为key值的String对象的hashCode()方法,获取能代表这个对象的唯一数值hashCode,定位这个键值对的实际存储地址,继而可以像数组一样通过array[index]这样的下标方式直接访问到目标元素。

由于String类型具备不可变的特性,因此在String对象内的hashCode()方法实际上只需执行一次计算过程,计算后把结果缓存到一个内部私有变量 int hash 中,而后每次需要调用这个String对象的hashCode()方法时,仅仅需要把上次的计算结果hash返回去即可,在物理上强效地保证了这个结果的绝对正确性,当HashMap需要频繁的读取访问任意一组键值对的时候,能节省非常多的CPU计算开销。

解释3:协助其他对象的使用

* 这一部分看得不是很懂,就笔主的浅显理解不能十分认同原文中的这个解释理由,这一块将按原文翻译与笔主的理解观点同步展示说明。

先展示一段不太真实的代码:

HashSet set = new HashSet();

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中将产生异常表现,在本文最后的补充环节,笔主将使用一小段代码进行模拟演示。

解释4:安全性

String被广泛用于网络连接、文件IO等多种Java基础类的参数中,如果String内容可变的话,将潜在地带来多种严重安全隐患,例如链接地址被暗中更改等,出于同样的原因,在Java反射机制中可变String参数也会导致潜在的安全威胁。

例如以下网络连接代码示例(修改自原文):

boolean connect(string url){

// 验证url地址是否安全,不安全的网络访问将被异常抛出阻止

if (!isSecure(url)) {

throw new SecurityException();

}

// 上一步url已通过安全检验,但如果url在这里能够被(其他线程)其他引用修改,将触发严重的安全威胁

mayCauseProblemWhileOpen(url);

}

解释5:不可变对象在物理上绝对性的线程安全

由于不可变对象内容不可能被修改,因此能在多线程中被任意自由访问而不会导致任何线程安全问题,同时也就不需要再做任何多余的同步操作开销。

总的来说,String的不可变特性设计就是出于效率和安全性的考虑,这也是其他类一般情况下更倾向于被设计成不可变特性的原因。

补充:当HashMap遇上可变对象并产生相同hashCode值...

在这里,笔主主要想讨论在解释3的***中提到的可变String对象产生相同hashCode值在HashMap中的异常表现问题。

先说明一个前提,String类中的hashCode()方法经过改写,与Object中的hashCode()不同,String中的hashCode()计算的唯一依据是String对象本身的字符串内容,如果存在两个内容同为"Monkey"的String对象,这两个对象经过hashCode()计算出的hashCode值将完全相同,被HashMap视为同一个key对象。

可变String模拟类:

1 package test;

2

3 /**

4 * 可变字符串模拟类

5 *

6 * @since 2014-6-21 下午6:14:16

7 * @author Wavky.Wand

8 */

9 public class ModifiableString {

10 private String mContent;

11

12 public ModifiableString(String content) {

13 mContent = content;

14 }

15

16 /**

17 * 更变字符串内容

18 *

19 * @param mContent

20 * the content to set

21 */

22 public void setContent(String mContent) {

23 this.mContent = mContent;

24 }

25

26 @Override

27 public int hashCode() {

28 return mContent.hashCode();

29 }

30

31 /**

32 * 依据Java类设计规则与HashMap需求,同时改写equals()方法,当两个对象hashCode相同时,equals()方法判断两个对象为相同

33 */

34 @Override

35 public boolean equals(Object obj) {

36 return obj.hashCode() == mContent.hashCode();

37 }

38 }

测试类:

1 package test;

2

3 import java.util.HashMap;

4

5 /**

6 *

7 * @since 2014-2-2 下午4:16:12

8 * @author Wavky.Wand

9 */

10 public class Test {

11

12 public static void main(String[] args) {

13 ModifiableString m1 = new ModifiableString("123");

14 ModifiableString m2 = new ModifiableString("456");

15 ModifiableString m3 = new ModifiableString("789");

16

17 // 输出三个对象的hashCode

18 out("m1 hashCode:" + m1.hashCode()); // 48690

19 out("m2 hashCode:" + m2.hashCode()); // 51669

20 out("m3 hashCode:" + m3.hashCode()); // 54648

21

22 // 初始化HashMap

23 HashMap map = new HashMap();

24 map.put(m1, "A");

25 map.put(m2, "B");

26 map.put(m3, "C");

27

28 // 输出初始化完毕后的HashMap

29 out("初始化完毕的HashMap");

30 out("map size:" + map.size()); // 3

31 out("map.get(m1):" + map.get(m1)); // A

32 out("map.get(m2):" + map.get(m2)); // B

33 out("map.get(m3):" + map.get(m3)); // C

34

35 out("迭代输出HashMap的所有key值");

36 for (ModifiableString m : map.keySet()) {

37 out(m); // @c9d5 @be32 @d578

38 }

39

40 out("迭代输出HashMap的所有key对应的value值");

41 for (ModifiableString m : map.keySet()) {

42 out(map.get(m)); // A B C 三个value值依次正常输出

43 }

44

45 out("迭代输出HashMap的所有value值");

46 for (String s : map.values()) {

47 out(s); // A B C 三个value值依次正常输出

48 }

49

50 // 更改m3的内容,与m1内容相同

51 out("m3.setContent(123)");

52 m3.setContent("123");

53

54 // 输出更改m3内容后的信息

55 out("m1 hashCode:" + m1.hashCode()); // 48690

56 out("m2 hashCode:" + m2.hashCode()); // 51669

57 out("m3 hashCode:" + m3.hashCode()); // 48690

58 out("m1==m3:" + (m1 == m3)); // false

59 out("m1.equals(m3):" + m1.equals(m3)); // true

60 out("重设m3内容后的HashMap");

61 out("map size:" + map.size()); // 3

62 out("map.get(m1):" + map.get(m1)); // A

63 out("map.get(m2):" + map.get(m2)); // B

64 // 因为m3内容与m1一致,hashCode与equal方法判断m3与m1相等,因此HashMap返回m1的内容,

65 // 而m3对应的value值C无法再通过key获取,类似于内存泄露状态

66 out("map.get(m3):" + map.get(m3)); // A

67

68 out("迭代输出HashMap的所有key值");

69 for (ModifiableString m : map.keySet()) {

70 out(m); // @be32 @c9d5 @be32 实际为16进制无符号hashCode值,第一个与第三个相同

71 }

72

73 out("迭代输出HashMap的所有key对应的value值");

74 for (ModifiableString m : map.keySet()) {

75 out(map.get(m)); // A B A 无法通过任何一个key获取到第三个value值C

76 }

77

78 out("迭代输出HashMap的所有value值");

79 for (String s : map.values()) {

80 out(s); // A B C 三个value值依次正常输出

81 }

82

83 // 移除HashMap中的m3键值对

84 out("map.remove(m3)");

85 map.remove(m3);

86

87 // 输出更改m3内容后的信息

88 out("删除m3内容后的HashMap");

89 out("map size:" + map.size()); // 2 HashMap内剩余两条键值对

90 out("map.get(m1):" + map.get(m1)); // null 通过m1获取value,无返回

91 out("map.get(m2):" + map.get(m2)); // B

92 out("map.get(m3):" + map.get(m3)); // null 通过m3获取value,无返回

93

94 out("迭代输出HashMap的所有key值");

95 for (ModifiableString m : map.keySet()) {

96 out(m); // @c9d5 @be32 m1或m3其中一个key被移除

97 }

98

99 out("迭代输出HashMap的所有key对应的value值");

100 for (ModifiableString m : map.keySet()) {

101 out(map.get(m)); // B null 无法通过任何一个key获取到原第三个value值C

102 }

103

104 out("迭代输出HashMap的所有value值");

105 for (String s : map.values()) {

106 out(s); // B C 显示实际上第一个键值对被删除,而最后一个未被删除,但无法获取到

107 }

108 }

109

110 static void out(Object o) {

111 System.out.println(o);

112 }

113

114 }

分析:

在这个略显冗长的测试类中,分别执行了三个主要步骤:

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[] 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中发挥出的重要作用。

分类: Java

评论留言区

:
  

作者: 游客 ; *
评论内容: *
带*号为必填项目

如一模式识别更新提示

matlab在图像处理方面的应用有更新

如一模式识别 友情链接

关于本站作者     chinaw3c     mozilla