萬盛學電腦網 >> 腳本專題 >> javascript >> Java的六大問題你都懂了嗎
Java的六大問題你都懂了嗎
這些問題對於認真學習java的人都要必知的，當然如果你只是初學者就沒必要那麼嚴格了，那如果你認為自己已經超越初學者了，卻不很懂這些問題，請將你自己重歸初學者行列。
一、到底要怎麼樣初始化！
本問題討論變量的初始化，所以先來看一下Java中有哪些種類的變量。
1.類的屬性，或者叫值域
2.方法裡的局部變量
3.方法的參數 對於第一種變量，Java虛擬機會自動進行初始化。如果給出了初始值，則初始化為該初始值。如果沒有給出，則把它初始化為該類型變量的默認初始值。
所有對象引用類型變量默認初始值為null，即不指向任何對象。注意數組本身也是對象，所以沒有初始化的數組引用在自動初始化後其值也是null.對於兩種不同的類屬性，static屬性與instance屬性，初始化的時機是不同的。instance屬性在創建實例的時候初始化，static屬性在類加載，也就是第一次用到這個類的時候初始化，對於後來的實例的創建，不再次進行初始化。這個問題會在以後的系列中進行詳細討論。對於第二種變量，必須明確地進行初始化。如果再沒有初始化之前就試圖使用它，編譯器會抗議。如果初始化的語句在try塊中或if塊中，也必須要讓它在第一次使用前一定能夠得到賦值。也就是說，把初始化語句放在只有if塊的條件判斷語句中編譯器也會抗議，因為執行的時候可能不符合if後面的判斷條件，如此一來初始化語句就不會被執行了，這就違反了局部變量使用前必須初始化的規定。但如果在else塊中也有初始化語句，就可以通過編譯，因為無論如何，總有至少一條初始化語句會被執行，不會發生使用前未被初始化的事情。對於try-catch也是一樣，如果只有在try塊裡才有初始化語句，編譯部通過。如果在catch或 finally裡也有，則可以通過編譯。總之，要保證局部變量在使用之前一定被初始化了。所以，一個好的做法是在聲明他們的時候就初始化他們，如果不知道要出事化成什麼值好，就用上面的默認值吧！其實第三種變量和第二種本質上是一樣的，都是方法中的局部變量。只不過作為參數，肯定是被初始化過的，傳入的值就是初始值，所以不需要初始化。
二、instanceof是什麼東東？
instanceof是Java的一個二元操作符，和==，>，<是同一類東東。由於它是由字母組成的，所以也是Java的保留關鍵字。它的作用是測試它左邊的對象是否是它右邊的類的實例，返回boolean類型的數據。然而，這種做法通常被認為是沒有好好利用面向對象中的多態性。其實上面的功能要求用方法重載完全可以實現，這是面向對象變成應有的做法，避免回到結構化編程模式。只要提供兩個名字和返回值都相同，接受參數類型不同的方法就可以了：所以，使用instanceof在絕大多數情況下並不是推薦的做法，應當好好利用多態。
三、“==”和equals方法究竟有什麼區別？
==操作符專門用來比較變量的值是否相等。比較好理解的一點是：根據前一帖說過，對象變量其實是一個引用，它們的值是指向對象所在的內存地址，而不是對象本身。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把這個任務留給了類的創建者。所以當你是用equals方法判斷對象的內容是否相等，請不要想當然。因為可能你認為相等，而這個類的作者不這樣認為，而類的equals方法的實現是由他掌握的。如果你需要使用equals方法，或者使用任何基於散列碼的集合 (HashSet，HashMap，HashTable)，請察看一下java doc以確認這個類的equals邏輯是如何實現的。[ nextpage]
四、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，意圖使得它“永遠不變”.其實那是徒勞的。
五、我聲明了什麼！
許多人都做過這樣的事情，但是，我們到底聲明了什麼？回答通常是：一個String，內容是“Hello world！”。這樣模糊的回答通常是概念不清的根源。如果要准確的回答，一半的人大概會回答錯誤。這個語句聲明的是一個指向對象的引用，名為“s”，可以指向類型為String的任何對象，目前指向“Hello world！”這個String類型的對象。這就是真正發生的事情。我們並沒有聲明一個String對象，我們只是聲明了一個只能指向String對象的引用變量。所以，如果在剛才那句語句後面，如果再運行一句：String string = s；我們是聲明了另外一個只能指向String對象的引用，名為string，並沒有第二個對象產生，string還是指向原來那個對象，也就是，和s指向同一個對象。
六、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調用構造器，總是會創建一個新的對象，無論內容是否相同。至於為
