Java中String类为什么被设计为final?
Java中String类为什么被设计为final
首先,String是引用类型,也就是每个字符串都是一个String实例。通过源码可以看到String底层维护了一个byte数组:private final byte[] value;
(JDK9中为byte数组,并非网上所说的char数组)。虽然该数组被修饰为final
,但这并不能保证数组的数据不会变化,因此还需要声明为private
防止被其他类修改数据。
被final修饰的类不能被继承,也就是不能有子类。那么为什么要把String设计为不能被继承呢?简单来说有两点:安全和效率。
安全
要知道String是一个非常非常基础的类,用处超级广泛,各种各样的类基本都使用到了字符串。
假设String类可以被继承,现在有一个方法method,该方法的参数为String类型,并且该方法利用到了字符串的长度特性:
我们设计出一个String的子类MyString,并重写了其长度方法:
基于Java的多态特性,当我们把MyString的实例作为参数传入method()方法时,编译器是不会报错的。但是我们的运行结果则完全错误,这会造成非常严重的后果。
相对于每次使用字符串的时候使用final修饰,直接把String类定义为final更为安全,效率也更高。并且,整个类声明为final之后,如果有一个String的引用,则它引用的一定是String对象,而不会是其他类的对象(泛型允许引用子类)。防止世界被熊孩子破坏2333
除了由多态引起的安全问题,还有引用类型本身的问题。
比如现在有两个方法,appendStr负责在不可变的String参数后添加“bbb”并返回,appendSb负责在可变的StringBuilder后添加“bbb”并返回。
但实际输出结果却是:
如果程序员不小心像上面例子里,直接在传进来的参数上加"bbb",因为Java对象参数传的是引用,所以可变的的StringBuffer参数就被改变了。可以看到变量sb在Test.appendSb(sb)
操作之后,就变成了"aaabbb"。有的时候这可能不是程序员的本意。所以String不可变的安全性就体现在这里。
再看下面这个HashSet用StringBuilder做元素的场景,问题就更严重了,而且更隐蔽。
这就破坏了HashSet键的唯一性,因此千万不要使用可变类型做HashMap和HashSet的键值。(不可变的字符串则非常适合作为键)
除了上述两种问题,不可变的字符串还可以保证多线程时的线程安全问题。多线程时,只有读操作一般不会引发线程安全问题,当读写同时存在时便容易引发安全问题。当字符串不可变时也就不能写,当然不会引发线程问题。
效率
基于字符串的不可变,才能有字符串常量池这一特性。字符串常量池的诞生是为了提升效率和减少内存分配。可以说我们编程有百分之八十的时间在处理字符串,而处理的字符串中有很大概率会出现重复的情况。正因为String的不可变性,常量池很容易被管理和优化。
并且1.7之前,字符串常量池在方法区,1.7之后在堆内存中,并且不仅仅可以存储对象,还可以存储对象的引用:
对于什么时候会在常量池存储字符串对象:
- 显示调用String的intern方法的时候,例如上例。
- 直接声明字符串字面常量的时候,例如:
String a = "aaa";
- 直接
new String("A")
方法的参数使用常量的时候 - 字符串直接常量相加的时候,例如:
String c = "aa" + "bb";
其中的aa/bb只要有任何一个不是字符串字面常量形式,都不会在常量池生成"aabb". 且此时jvm做了优化,不会同时生成"aa"和"bb"在字符串常量池中
顺便说一句,Integer、Long、Double……这几个包装类也是final的~