每个学 Java 的人都应该搞懂

本文详细探讨了 Java 中 String 类的特性,包括引用与对象的区别、==与 equals 的差异、String 的不可变性及其带来的内存管理影响,以及 final 关键字的作用范围。

每个学 Java 的人都应该搞懂

http://www.cnblogs.com/benshing/archive/2006/12/17/595097.html     分享


问题一: 我声明了什么!
String s = "Hello world!";
许多人都做过这样的事情,但是,我们到底声明了什么?回答通常是:一个 String ,内容是 “Hello world!” 。这样模糊的回答通常是概念不清的根源。如果要准确的回答,一半的人大概会回答错误。
这个语句声明的是一个指向对象的引用,名为 “s” ,可以指向类型为 String 的任何对象,目前指向 "Hello world!" 这个 String 类型的对象。这就是真正发生的事情。我们并没有声明一个 String 对象,我们只是声明了一个只能指向 String 对象的引用变量。所以,如果在刚才那句语句后面,如果再运行一句:

String string = s;
我们是声明了另外一个只能指向 String 对象的引用,名为 string ,并没有第二个对象产生, string 还是指向原来那个对象,也就是,和 s 指向同一个对象。

问题二: "==" equals 方法究竟有什么区别?



问题三: String 到底变了没有?
没有。因为 String 被设计成不可变 (immutable) 类,所以它的所有对象都是不可变对象。请看下列代码:

String s = "Hello";
s = s + " world!";
s
所指向的对象是否改变了呢?从本系列第一篇的结论很容易导出这个结论。我们来看看发生了什么事情。在这段代码中, s 原先指向一个 String 对象,内容是 "Hello" ,然后我们对 s 进行了 + 操作,那么 s 所指向的那个对象是否发生了改变呢?答案是没有。这时, s 不指向原来那个对象了,而指向了另一个 String 对象,内容为 "Hello world!" ,原来那个对象还存在于内存之中,只是 s 这个引用变量不再指向它了。

通过上面的说明,我们很容易导出另一个结论,如果经常对字符串进行各种各样的修改,或者说,不可预见的修改,那么使用 String 来代表字符串的话会引起很大的内存开销。因为 String 对象建立之后不能再改变,所以对于每一个不同的字符串,都需要一个 String 对象来表示。这时,应该考虑使用 StringBuffer 类,它允许修改,而不是每个不同的字符串都要生成一个新的对象。并且,这两种类的对象转换十分容易。

同时,我们还可以知道,如果要使用内容相同的字符串,不必每次都 new 一个 String 例如我们要在构造器中对一个名叫 s String 引用变量进行初始化,把它设置为初始值,应当这样做:

public class Demo {
   private String s;
   ...
   public Demo {
     s = "Initial Value";
   }
   ...
}
而非
s = new String("Initial Value");
后者每次都会调用构造器,生成新对象,性能低下且内存开销大,并且没有意义,因为 String 对象不可改变,所以对于内容相同的字符串,只要一个 String 对象来表示就可以了。也就说,多次调用上面的构造器创建多个对象,他们的 String 类型属性 s 都指向同一个对象。

上面的结论还基于这样一个事实:对于字符串常量,如果内容相同, Java 认为它们代表同一个 String 对象。而用关键字 new 调用构造器,总是会创建一个新的对象,无论内容是否相同。

至于为什么要把 String 类设计成不可变类,是它的用途决定的。其实不只 String ,很多 Java 标准类库中的类都是不可变的。在开发一个系统的时候,我们有时候也需要设计不可变类,来传递一组相关的值,这也是面向对象思想的体现。不可变类有一些优点,比如因为它的对象是只读的,所以多线程并发访问也不会有任何问题。当然也有一些缺点,比如每个不同的状态都要一个对象来代表,可能会造成性能上的问题。所以 Java 标准类库还提供了一个可变版本,即 StringBuffer


问题四: final 关键字到底修饰了什么?

final
使得被修饰的变量 " 不变 " ,但是由于对象型变量的本质是引用,使得不变也有了两种含义:引用本身的不变,和引用指向的对象不变。


引用本身的不变:

final StringBuffer a=new StringBuffer("immutable");
final StringBuffer b=new StringBuffer("not immutable");
a=b;//
编译期错误


引用指向的对象不变:

final StringBuffer a=new StringBuffer("immutable");
a.append(" broken!"); //
编译通过


可见, final 只对引用的 ”( 也即它所指向的那个对象的内存地址 ) 有效,它迫使引用只能指向初始指向的那个对象,改变它的指向会导致编译期错误。至于它所指向的对象的变化, final 是不负责的。这很类似 == 操作符: == 操作符只负责引用的相等,至于这个地址所指向的对象内容是否相等, == 操作符是不管的。


理解 final 问题有很重要的含义。许多程序漏洞都基于此 ----final 只能保证引用永远指向固定对象,不能保证那个对象的状态不变。在多线程的操作中 , 一个对象会被多个线程共享或修改,一个线程对对象无意识的修改可能会导致另一个使用此对象的线程崩溃。一个错误的解决方法就是在此对象新建的时候把它声明为 final ,意图使得它永远不变。其实那是徒劳的

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值