Java從出生到現在已經25年了，數據不一定能完美的衡量技術的價值，但是在不斷推陳出新的技術推廣壓力下，Java語言依然能夠牢牢占據市場份額榜首自然有它的強大之處。Java如此強大，轉行來學Java的人與日俱增。這就造成了，招聘市場上初級Java程序員越來越多的現象。

任何一個Java初學者如果認為自己已經能夠脫離初學者的范疇，那么都可以用以下的幾個問題對自己進行考量。如果你還不能夠弄懂這些問題，那么請將自己重新歸入初學者的隊伍中。

問題一：我聲明什么！

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。

因此，學互聯網技術不能猶豫，否則你就和高薪擦肩而過了。不論你是0基礎還是轉行，都有大牛老師手把手教你學習最新熱門技術，找一份自己滿意的高薪工作。