闂傚倸鍊搁崐鎼佸磹瀹勬噴褰掑炊椤掆偓杩濋梺閫炲苯澧撮柡灞剧〒閳ь剨缍嗛崑鍛暦瀹€鍕厸鐎光偓閳ь剟宕伴弽顓溾偓浣糕槈濡嘲鐗氶梺鍛婂姉閸嬫挸袙婢跺绻嗛柣鎰典簻閳ь剚鍨垮畷鏇熺節濮橆剛顔嗛梺璺ㄥ櫐閹凤拷 (0) +1 闂傚倸鍊搁崐宄懊归崶褏鏆﹂柛顭戝亝閸欏繒鈧箍鍎遍幏瀣触鐎n喗鐓曢柍鈺佸枤濞堛垹霉绾攱瀚� (0) +1 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂撮檷閸嬫垿鎮楀☉娆嬬細妞も晜鐓¢弻锝夊箣閿濆棭妫勭紓浣哄閸ㄥ爼寮婚妸鈺傚亞闁稿本绋戦锟� (0) +1
闂傚倸鍊搁崐鎼佸磹瀹勬噴褰掑炊椤掆偓杩濋梺閫炲苯澧撮柡灞剧〒閳ь剨缍嗛崑鍛暦瀹€鍕厸鐎光偓閳ь剟宕伴弽顓溾偓浣糕槈濡嘲鐗氶梺鍛婂姉閸嬫挸袙婢跺绻嗛柣鎰典簻閳ь剚鍨垮畷鏇㈠蓟閵夈儱鐎梺绉嗗嫷娈旈柦鍐枛閺岋綁寮崶銉㈠亾閳ь剟鏌涚€n偅灏柍钘夘槸閳诲秹顢樿缁ㄥジ鏌熸笟鍨鐎规洘鍎奸ˇ顕€鏌¢埀顒勬嚍閵夛絼绨婚梺鍝勬川閸嬬偤藟閻愮儤鍊垫慨妯煎亾鐎氾拷闂傚倸鍊搁崐鎼佸磹妞嬪海鐭嗗〒姘e亾妤犵偞鐗犻、鏇㈠Χ閸℃ぞ绮℃俊鐐€栭崝褏绮婚幋鐘差棜闁秆勵殕閻撴洟鏌熼柇锕€鐏遍柛銈咁儔閺屻倝寮堕幐搴′淮闂佸搫鏈粙鎴﹀煡婢跺ň鏋庨柟閭﹀枤閳诲繒绱撻崒姘偓椋庢媼閺屻儱鐤鹃柣妯款嚙閽冪喖鏌i弮鍌楁嫛闁轰礁绉电换婵囩節閸屾碍鐏撻梺鍝勬-閸樺ジ鈥旈崘顔嘉ч柛鎰╁妼婵兘姊洪悷鏉挎闁瑰嚖鎷�>>

正在阅读:每个Java初学者都应该搞懂的六个问题每个Java初学者都应该搞懂的六个问题

2006-07-19 09:27 出处: 作者:雷少 责任编辑:xietaoming

  问题三: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,意图使得它“永远不变”。其实那是徒劳的。

键盘也能翻页,试试“← →”键

关注我们

最新资讯离线随时看 聊天吐槽赢奖品
闂傚倸鍊搁崐鎼佸磹妞嬪海鐭嗗ù锝堟缁€濠傗攽閻樻彃鈧绱撳杈ㄥ枑闁哄啫鐗勯埀顑跨窔瀵粙顢橀悙鑼垛偓鍨攽閿涘嫬浠х紒顕呭灦瀵偊鎮╃紒妯锋嫼闂備緡鍋嗛崑娑㈡嚐椤栨稒娅犻柟缁㈠枟閻撴瑦銇勯弮鈧娆忈缚閹扮増鐓欑€瑰嫮澧楅崵鍥┾偓瑙勬磸閸斿秶鎹㈠┑瀣<婵炲棙鍔栭埢鏇熺節閻㈤潧啸妞わ綀妫勫嵄闁告稒娼欑壕濠氭煙閹规劦鍤欑紒鐙€鍨堕弻銊╂偆閸屾稑顏�闂傚倸鍊搁崐鎼佸磹閻戣姤鍊块柨鏇炲€哥粻鏍煕椤愶絾绀€缁炬儳娼¢弻鐔煎箚閻楀牜妫勭紒鎯у⒔缁垳鎹㈠☉銏犵婵炲棗绻掓禒濂告⒑閸濆嫬顏ラ柛搴f暬楠炲啫顫滈埀顒勫箖濞嗘挸绾ч柛顭戝枤瑜版垵鈹戦悙鑼憼缂侇喖绉堕崚鎺楀箻鐠囪尪鎽曞┑鐐村灟閸╁嫰寮崘顔界叆婵犻潧妫欓ˉ鐘炽亜閿斿搫鍔︽慨濠冩そ瀹曘劍绻濋崘鐐棝闂備胶鎳撻崵鏍箯閿燂拷