JAVA的一些基本問題(轉)

JAVA的一些基本問題(轉)[@more@]

引用本身的不變：

　　final StringBuffer a=new StringBuffer("immutable");

　　final StringBuffer b=new StringBuffer("not immutable");

　　a=b;//編譯期錯誤 …………》》》

問題一：我宣告瞭什麼！

　　String s = "Hello world!";

　　

　　許多人都做過這樣的事情，但是，我們到底宣告瞭什麼？回答通常是：一個String，內容是“Hello world!”。這樣模糊的回答通常是概念不清的根源。如果要準確的回答，一半的人大概會回答錯誤。

　　

　　這個語句宣告的是一個指向物件的引用，名為“s”，可以指向型別為String的任何物件，目前指向"Hello world!"這個String型別的物件。這就是真正發生的事情。我們並沒有宣告一個String物件，我們只是宣告瞭一個只能指向String物件的引用變數。所以，如果在剛才那句語句後面，如果再執行一句：

　　

　　String string = s;

　　

　　我們是宣告瞭另外一個只能指向String物件的引用，名為string，並沒有第二個物件產生，string還是指向原來那個物件，也就是，和s指向同一個物件。

　　

　　問題二："=="和equals方法究竟有什麼區別？

　　

　　==運算子專門用來比較變數的值是否相等。比較好理解的一點是：

　　int a=10;

　　int b=10;

　　則a==b將是true。

　　但不好理解的地方是：

　　String a=new String("foo");

　　String b=new String("foo");

　　則a==b將返回false。

　　

　　根據前一帖說過，物件變數其實是一個引用，它們的值是指向物件所在的記憶體地址，而不是物件本身。a和b都使用了new運算子，意味著將在記憶體中產生兩個內容為"foo"的字串，既然是“兩個”，它們自然位於不同的記憶體地址。a和b的值其實是兩個不同的記憶體地址的值，所以使用"=="運算子，結果會是 false。誠然，a和b所指的物件，它們的內容都是"foo"，應該是“相等”，但是==運算子並不涉及到物件內容的比較。

　　

　　物件內容的比較，正是equals方法做的事。

　　

　　看一下Object物件的equals方法是如何實現的：

　　boolean equals(Object o){

　　

　　return this==o;

　　

　　}

　　Object 物件預設使用了==運算子。所以如果你自創的類沒有覆蓋equals方法，那你的類使用equals和使用==會得到同樣的結果。同樣也可以看出， Object的equals方法沒有達到equals方法應該達到的目標：比較兩個物件內容是否相等。因為答案應該由類的建立者決定，所以Object把這個任務留給了類的建立者。

　　

　　看一下一個極端的類：

　　Class Monster{

　　private String content;

　　...

　　boolean equals(Object another){ return true;}

　　

　　}

　　我覆蓋了equals方法。這個實現會導致無論Monster例項內容如何，它們之間的比較永遠返回true。

　　

　　所以當你是用equals方法判斷物件的內容是否相等，請不要想當然。因為可能你認為相等，而這個類的作者不這樣認為，而類的equals方法的實現是由他掌握的。如果你需要使用equals方法，或者使用任何基於雜湊碼的集合（HashSet,HashMap,HashTable），請察看一下 java doc以確認這個類的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，意圖使得它“永遠不變”。其實那是徒勞的。

　　

　　問題五：到底要怎麼樣初始化！

　　

　　本問題討論變數的初始化，所以先來看一下Java中有哪些種類的變數。

　　

　　1. 類的屬性，或者叫值域

　　

　　2. 方法裡的區域性變數

　　

　　3. 方法的引數

　　

　　對於第一種變數，Java虛擬機器會自動進行初始化。如果給出了初始值，則初始化為該初始值。如果沒有給出，則把它初始化為該型別變數的預設初始值。

　　

　　int型別變數預設初始值為0

　　

　　float型別變數預設初始值為0.0f

　　

　　double型別變數預設初始值為0.0

　　

　　boolean型別變數預設初始值為false

　　

　　char型別變數預設初始值為0(ASCII碼)

　　

　　long型別變數預設初始值為0

　　

　　所有物件引用型別變數預設初始值為null，即不指向任何物件。注意陣列本身也是物件，所以沒有初始化的陣列引用在自動初始化後其值也是null。

　　

　　對於兩種不同的類屬性，static屬性與instance屬性，初始化的時機是不同的。instance屬性在建立例項的時候初始化，static屬性在類載入，也就是第一次用到這個類的時候初始化，對於後來的例項的建立，不再次進行初始化。這個問題會在以後的系列中進行詳細討論。

　　

　　對於第二種變數，必須明確地進行初始化。如果再沒有初始化之前就試圖使用它，編譯器會抗議。如果初始化的語句在try塊中或if塊中，也必須要讓它在第一次使用前一定能夠得到賦值。也就是說，把初始化語句放在只有if塊的條件判斷語句中編譯器也會抗議，因為執行的時候可能不符合if後面的判斷條件，如此一來初始化語句就不會被執行了，這就違反了區域性變數使用前必須初始化的規定。但如果在else塊中也有初始化語句，就可以透過編譯，因為無論如何，總有至少一條初始化語句會被執行，不會發生使用前未被初始化的事情。對於try-catch也是一樣，如果只有在try塊裡才有初始化語句，編譯部透過。如果在 catch或finally裡也有，則可以透過編譯。總之，要保證區域性變數在使用之前一定被初始化了。所以，一個好的做法是在宣告他們的時候就初始化他們，如果不知道要出事化成什麼值好，就用上面的預設值吧！

　　

　　其實第三種變數和第二種本質上是一樣的，都是方法中的區域性變數。只不過作為引數，肯定是被初始化過的，傳入的值就是初始值，所以不需要初始化。

　　

　　問題六：instanceof是什麼東東？

　　

　　instanceof是Java的一個二元運算子，和==，>，　　

　　String s = "I AM an Object!";

　　boolean isObject = s instanceof Object;

　　

　　我們宣告瞭一個String物件引用，指向一個String物件，然後用instancof來測試它所指向的物件是否是Object類的一個例項，顯然，這是真的，所以返回true，也就是isObject的值為True。

　　instanceof有一些用處。比如我們寫了一個處理賬單的系統，其中有這樣三個類：

　　

　　public class Bill

　　public class PhoneBill extends Bill

　　public class GasBill extends Bill

　　

　　在處理程式裡有一個方法，接受一個Bill型別的物件，計算金額。假設兩種賬單計算方法不同，而傳入的Bill物件可能是兩種中的任何一種，所以要用instanceof來判斷：

　　

　　public double calculate(Bill bill) {

　　if (bill instanceof PhoneBill) {

　　//計算電話賬單

　　}

　　if (bill instanceof GasBill) {

　　//計算燃氣賬單

　　}

　　...

　　}

　　這樣就可以用一個方法處理兩種子類。

　　

　　然而，這種做法通常被認為是沒有好好利用物件導向中的多型性。其實上面的功能要求用方法過載完全可以實現，這是物件導向變成應有的做法，避免回到結構化程式設計模式。只要提供兩個名字和返回值都相同，接受引數型別不同的方法就可以了：

　　

　　public double calculate(PhoneBill bill) {

　　//計算電話賬單

　　}

　　

　　public double calculate(GasBill bill) {

　　//計算燃氣賬單

　　}

　　

　　所以，使用instanceof在絕大多數情況下並不是推薦的做法，應當好好利用多型