为什么 jdk 中把 String 类设计成 final


最佳答案:

主要是为了 “ 效率 ” 和 “ 安全性 ” 的缘故。 若 String 允许被继承, 由于它的高度被使用率, 可能会降低程序的性能,所以 String 被定义成 final。

其它答案一:

String 和其他基本类型不同 , 他是个对象类型. 既然是对象类型 , 如果是在静态方法下是必须调用静态方法或值的 , 如果是非静态的方法 , 就必须要实例化.

main 函数是个 static 的. 所以 String 要能像其他的基本类型一样直接被调用. 这也是为什么在 main 函数下使用 String 类型不会报告错误的原因..

一下就解释了两个心里的疑问..

以前一直觉得奇怪 , 为什么 String 是对象类型在 main 函数下却是不需要实例化的. 再次佩服 java 设计人员想得真周到.

其它答案二:

当定义 String 类型的静态字段(也成类字段),可以用静态变量(非 final)代替常量(final)加快程序速度。 反之,对于原始数据类型,例如 int,也成立。

例如,你可能创建一个如下的 String 对象:

private static final String x = "example"; 

对于这个静态常量(由 final 关键字标识),你使用常量的每个时候都会创建一个临时的 String 对象。 在字节代码中,编译器去掉 ”x”,代替它的是字符串 “example”, 以致每次引用 ”x” 时 VM 都会进行一次哈希表查询。

相比之下,度于静态变量 ( 非 final 关键字 ),字符串只创建一次。 仅当初始化 “x” 时, VM 才进行哈希表查询。

还有另一个解释 :

带有 final 修饰符的类是不可派生的。 在 java 核心 API 中,有许多应用 final 的例子,例如 java.lang.String。 为 String 类指定 final 防止了人们覆盖 length() 方法。

另外,如果指定一个类为 final,则该类所有的方法都是 final。 java 编译器会寻找机会内联(inline)所有的 final 方法(这和具体的编译器实现有关)。 此举能够使性能平均提高 50%。

示例:

public class Test { 
    public static void main(String[] args)  { 
        //  
    } 
} 

如果 String 不是 final 那么就可以继承

public class String2 extends String{ 
   //.. 
   //... 
} 

那我们的 main 也就可以写成

public class Test { 
    public static void main(String2[] args)  { // 注意此处 
        //  
    } 
} 

英文参考: http://forums.sun.com/thread.jspa?threadID=636414

另外补充一点:

作用就是 final的类不能被继承,不能让别人继承有什么好处?

意义就在于,安全性,如此这般:

java 自出生那天起就是“为人民服务”,这也就是为什么java做不了病毒,也不一定非得是病毒,反正总之就是为了安全, 人家java的开发者目的就是不想让 java干这类危险的事儿,java并不是操作系统本地语言, 换句话说java必须借助操作系统本身的力量才能做事,JDK中提供的好多核心类比如 String,这类的类的内部好多方法的实现都不是java编程语言本身编写的, 好多方法都是调用的操作系统本地的API,这就是著名的“本地方法调用”,也只有这样才能做事,这种类是非常底层的, 和操作系统交流频繁的,那么如果这种类可以被继承的话,如果我们再把它的方法重写了,往操作系统内部写入一段具有恶意攻击性质的代码什么的, 这不就成了核心病毒了么?

上面所述是最重要的,另外一个方面,上面2位老兄说的也都很对, 就是不希望别人改,这个类就像一个工具一样,类的提供者给我们提供了, 就希望我们直接用就完了,不想让我们随便能改,其实说白了还是安全性, 如果随便能改了,那么java编写的程序肯定就很不稳定,你可以保证自己不乱改, 但是将来一个项目好多人来做,管不了别人,再说有时候万一疏忽了呢?他也不是估计的, 所以这个安全性是很重要的,java和C++相比,优点之一就包括这一点;

原因绝对不只有这么多,因为如果这些个核心的类都能被随便操作的话,那是很恐怖的,会出现好多好多未知的错误,莫名其妙的错误….



本作品由 追风少年 创作,采用 CC BY-NC-SA 3.0 许可协议 进行许可。

Comments