java必須理解的幾個小問題

問題一：我聲明瞭什麼！

1. String s = "Hello world!"; 

許多人都作過這樣的事情，可是，咱們到底聲明瞭什麼？回答一般是：一個String，內容是「Hello world!」。這樣模糊的回答一般是概念不清的根源。若是要準確的回答，一半的人大概會回答錯誤。

這個語句聲明的是一個指向對象的引用，名爲「s」，能夠指向類型爲String的任何對象，目前指向"Hello world!"這個String類型的對象。這就是真正發生的事情。咱們並無聲明一個String對象，咱們只是聲明瞭一個只能指向String對象的 引用變量。因此，若是在剛纔那句語句後面，若是再運行一句：

1. String string = s; 

咱們是聲明瞭另一個只能指向String對象的引用，名爲string，並無第二個對象產生，string仍是指向原來那個對象，也就是，和s指向同一個對象。

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

==操做符專門用來比較變量的值是否相等。比較好理解的一點是：

1. int a=10;  
2. int b=10;  
3. 則a==b將是true。  
4. 但很差理解的地方是：  
5. String a=new String("foo");  
6. String b=new String("foo");  
7. 則a==b將返回false。 

根據前一帖說過，對象變量實際上是一個引用，它們的值是指向對象所在的內存地址，而不是對象自己。a和b都使用了new操做符，意味着將在內存中產生 兩個內容爲"foo"的字符串，既然是「兩個」，它們天然位於不一樣的內存地址。a和b的值實際上是兩個不一樣的內存地址的值，因此使用"=="操做符，結果會 是false。誠然，a和b所指的對象，它們的內容都是"foo"，應該是「相等」，可是==操做符並不涉及到對象內容的比較。
對象內容的比較，正是equals方法作的事。

看一下Object對象的equals方法是如何實現的：

1. boolean equals(Object o){  
2.  
3. return this==o;  
4.  
5. }  

Object對象默認使用了==操做符。因此若是你自創的類沒有覆蓋equals方法，那你的類使用equals和使用==會獲得一樣的結果。一樣 也能夠看出，Object的equals方法沒有達到equals方法應該達到的目標：比較兩個對象內容是否相等。由於答案應該由類的建立者決定，因此 Object把這個任務留給了類的建立者。

看一下一個極端的類：

1. Class Monster{  
2. private String content;  
3. ...  
4. boolean equals(Object another){ return true;}  
5.  
6. }  
7.  

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

因此當你是用equals方法判斷對象的內容是否相等，請不要想固然。由於可能你認爲相等，而這個類的做者不這樣認爲，而類的equals方法的實 現是由他掌握的。若是你須要使用equals方法，或者使用任何基於散列碼的集合（HashSet,HashMap,HashTable），請察看一下 java doc以確認這個類的equals邏輯是如何實現的。

 

咱們來總結一下
== 和equals()兩種比較方法，在使用時要注意：
一、若是測試兩個簡單類型的數值是否相等，則必定要用「==」來比較；
二、若是要比較兩個引用變量對象的值是否相等，則要用對象的equals()方法進行比較；
三、若是須要比較兩個引用變量是否指向同一對象，則使用「==」來進行比較；
還有，對於自定義的類，應該根據狀況覆蓋其父類或Object類中的equals()方法，不然默認的equals()方法功能與「==」相同。

問題三：String到底變了沒有？

沒有。由於String被設計成不可變(immutable)類，因此它的全部對象都是不可變對象。請看下列代碼：

1. String s = "Hello";  
2. s = s + " world!"; 

s所指向的對象是否改變了呢？從本系列第一篇的結論很容易導出這個結論。咱們來看看發生了什麼事情。在這段代碼中，s原先指向一個String對 象，內容是"Hello"，而後咱們對s進行了+操做，那麼s所指向的那個對象是否發生了改變呢？答案是沒有。這時，s不指向原來那個對象了，而指向了另 一個String對象，內容爲"Hello world!"，原來那個對象還存在於內存之中，只是s這個引用變量再也不指向它了。
經過上面的說明，咱們很容易導出另外一個結論，若是常常對字符串進行各類各樣的修改，或者說，不可預見的修改，那麼使用String來表明字符串的話會引發 很大的內存開銷。由於String對象創建以後不能再改變，因此對於每個不一樣的字符串，都須要一個String對象來表示。這時，應該考慮使用 StringBuffer類，它容許修改，而不是每一個不一樣的字符串都要生成一個新的對象。而且，這兩種類的對象轉換十分容易。
同時，咱們還能夠知道，若是要使用內容相同的字符串，沒必要每次都new一個String。例如咱們要在構造器中對一個名叫s的String引用變量進行初始化，把它設置爲初始值，應當這樣作：

1. public class Demo {  
2. private String s;  
3. ...  
4. public Demo {  
5. s = "Initial Value";  
6. }  
7. ...  
8. } 

而非

1. s = new String("Initial Value");  

後者每次都會調用構造器，生成新對象，性能低下且內存開銷大，而且沒有意義，由於String對象不可改變，因此對於內容相同的字符串，只要一個String對象來表示就能夠了。也就說，屢次調用上面的構造器建立多個對象，他們的String類型屬性s都指向同一個對象。

上面的結論還基於這樣一個事實：對於字符串常量，若是內容相同，Java認爲它們表明同一個String對象。而用關鍵字new調用構造器，老是會建立一個新的對象，不管內容是否相同。

至於爲何要把String類設計成不可變類，是它的用途決定的。其實不僅String，不少Java標準類庫中的類都是不可變的。在開發一個系統 的時候，咱們有時候也須要設計不可變類，來傳遞一組相關的值，這也是面向對象思想的體現。不可變類有一些優勢，好比由於它的對象是隻讀的，因此多線程併發 訪問也不會有任何問題。固然也有一些缺點，好比每一個不一樣的狀態都要一個對象來表明，可能會形成性能上的問題。因此Java標準類庫還提供了一個可變版本， 即StringBuffer。

問題四：final關鍵字到底修飾了什麼？

final使得被修飾的變量"不變"，可是因爲對象型變量的本質是「引用」，使得「不變」也有了兩種含義：引用自己的不變，和引用指向的對象不變。

引用自己的不變：

1. final StringBuffer a=new StringBuffer("immutable");  
2. final StringBuffer b=new StringBuffer("not immutable");  
3. a=b;//編譯期錯誤 

引用指向的對象不變：

1. final StringBuffer a=new StringBuffer("immutable");  
2. a.append(" broken!"); //編譯經過 

可見，final只對引用的「值」(也即它所指向的那個對象的內存地址)有效，它迫使引用只能指向初始指向的那個對象，改變它的指向會致使編譯期錯 誤。至於它所指向的對象的變化，final是不負責的。這很相似==操做符：==操做符只負責引用的「值」相等，至於這個地址所指向的對象內容是否相 等，==操做符是無論的。

理解final問題有很重要的含義。許多程序漏洞都基於此----final只能保證引用永遠指向固定對象，不能保證那個對象的狀態不變。在多線程 的操做中,一個對象會被多個線程共享或修改，一個線程對對象無心識的修改可能會致使另外一個使用此對象的線程崩潰。一個錯誤的解決方法就是在此對象新建的時 候把它聲明爲final，意圖使得它「永遠不變」。其實那是徒勞的。

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

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

1. 1. 類的屬性，或者叫值域  
2. 2. 方法裏的局部變量  
3. 3. 方法的參數 

對於第一種變量，Java虛擬機會自動進行初始化。若是給出了初始值，則初始化爲該初始值。若是沒有給出，則把它初始化爲該類型變量的默認初始值。

1. int類型變量默認初始值爲0  
2. float類型變量默認初始值爲0.0f  
3. double類型變量默認初始值爲0.0  
4. boolean類型變量默認初始值爲false  
5. char類型變量默認初始值爲0(ASCII碼)  
6. long類型變量默認初始值爲0  
7. 全部對象引用類型變量默認初始值爲null，即不指向任何對象。注意數組自己也是對象，因此沒有初始化的數組引用在自動初始化後其值也是null。 

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

對於第二種變量，必須明確地進行初始化。若是再沒有初始化以前就試圖使用它，編譯器會抗議。若是初始化的語句在try塊中或if塊中，也必需要讓它 在第一次使用前必定可以獲得賦值。也就是說，把初始化語句放在只有if塊的條件判斷語句中編譯器也會抗議，由於執行的時候可能不符合if後面的判斷條件， 如此一來初始化語句就不會被執行了，這就違反了局部變量使用前必須初始化的規定。但若是在else塊中也有初始化語句，就能夠經過編譯，由於不管如何，總 有至少一條初始化語句會被執行，不會發生使用前未被初始化的事情。對於try-catch也是同樣，若是隻有在try塊裏纔有初始化語句，編譯部經過。如 果在catch或finally裏也有，則能夠經過編譯。總之，要保證局部變量在使用以前必定被初始化了。因此，一個好的作法是在聲明他們的時候就初始化 他們，若是不知道要出事化成什麼值好，就用上面的默認值吧！

其實第三種變量和第二種本質上是同樣的，都是方法中的局部變量。只不過做爲參數，確定是被初始化過的，傳入的值就是初始值，因此不須要初始化。