• 五花肉備好　
• 五花肉下鍋
• 五花肉出鍋　　

3.如何理解多態(tài)

父類引用指向子類的實例：例如：

List<Object> list = new ArrayList<>();

4、封裝舉例？

實體類的封裝，將屬性私有，只有本類能訪問，如此就對信息進行的隱藏。對每個值屬性提供對外的公共方法訪問，也就是創(chuàng)建一對賦取值方法，用于對私有屬性的訪問

5、繼承？

Java是單繼承的，子類從父類繼承方法，使得子類具有父類相同的行為

6、char可不可以存儲一個中文漢字，為什么？

char型變量是用來存儲Unicode編碼的字符的，unicode編碼字符集中包含漢字,所以可以存儲，有些特殊的漢字沒有包含在Unicode中，就不能存儲了，Unicode編碼占用兩個字節(jié)，所以，char類型的變量也是占用兩個字節(jié)

7、自動拆裝箱？int和integer有什么區(qū)別？

裝箱：將基本數(shù)據(jù)類型轉(zhuǎn)換為包裝類對象

拆箱：將包裝類對象轉(zhuǎn)換成基本類型的值

裝箱使用包裝器的valueOf方法，拆箱使用包裝器的intValue方法。

為什么要引入自動拆裝箱？主要用于Java的集合中，集合類型只能指定包裝類，List list = new Arraylist<>();

原理？Java編譯器的語法糖。

語法糖 Syntactic Sugar 糖衣語法，方便開發(fā)人員使用，JVM并不識在編譯階段解語法糖，還原為基礎語法

  public static void main(String[] args) {
    Integer a = 127;
    Integer b = 127;
    Integer c = 128;
    Integer d = 128;
    System.out.println(a == b); // true
    System.out.println(c == d); // false
  }
java中基本類型的包裝類的大部分都實現(xiàn)了常量池技術，這些類是Byte,Short,Integer,Long,Character,Boolean,另外兩種浮點數(shù)類型的包裝類則沒有實現(xiàn)。另外Byte,Short,Integer,Long,Character這5種整型的包裝類也只是在對應值小于等于127時才可使用對象池。超過了就要申請空間創(chuàng)建對象了

8、 == 和 equals 的區(qū)別？

==

比較基本數(shù)據(jù)類型：比較的是變量的值

比較引用數(shù)據(jù)類型：比較的是地址值

equals

如果沒重寫equals方法比較的是兩個對象的地址值

如果重寫的了equals方法后我們往往比較的是對象中的屬性的內(nèi)容

equals沖Object類中繼承過來的，默認的實現(xiàn)就是使用==

public boolean equals(Object obj){
		return (this==obj)
}

9、String可以被繼承嗎？

不能被繼承，因為String類有final修飾符，而final修飾的類是不能被繼承的

• String類是最常用的類之一，為了效率，禁止被繼承和重寫為什么用final修飾？
• 為了安全。String類中有很多調(diào)用底層的本地方法，調(diào)用操作系統(tǒng)的API，如果方法可以重寫，可能被植入惡意代碼，破壞程序。Java的安全性也體現(xiàn)在這里】

10、String buffer和String Builder的區(qū)別？

1、String buffer和String builder中的方法和功能是完全等價的

2、只是StringBuffer中的方法大都采用了synchronize關鍵字進行修飾，因此是線程安全的，而StringBuilder沒有這個修飾，可以被認為是線程不安全的

3、在單線程的程序下，StringBuilder效率更快，因為它不需要加鎖，不具備多線程安全而StringBuffer則每次都需要對鎖進行判斷，效率相對更低

11、final、finally、Finalize有什么區(qū)別？

final：修飾符（關鍵字） 有三種用法：修飾類、變量、和方法，

修飾類時，意味著他不能再派生出新的子類，即不能被繼承，因此它和abstract是反義詞。

修飾變量時，該變量使用中不被改變，必須在聲明時給定初始值，在引用中只能讀取不可修改，即為常量。

修飾方法時，也同樣只能使用，不能在子類中被重寫。

finally：通常放在try……catch的后面構(gòu)造最終執(zhí)行代碼塊，這就意味著程序無論正常執(zhí)行還是發(fā)生異常，這里的代碼只要JVM不關閉都能執(zhí)行，可以將釋放外部資源的代碼寫在finally塊中

finalize：Object類中定義的方法，Java中允許使用finalize()方法在垃圾收集器將對象從內(nèi)存中清除出去之前做必要的清理工作，這個方法是由垃圾收集器在銷毀對象時調(diào)用的，通過重寫finalize() 方法可以整理系統(tǒng)資源或者執(zhí)行其他清理工作

12、Object中有哪些方法？

（1）protected Object clone()--->創(chuàng)建并返回此對象的一個副本。

（2）boolean equals(Object obj)--->指示某個其他對象是否與此對象“相等”。

（3）protected void finalize()--->當垃圾回收器確定不存在對該對象的更多引用時，由對象的垃圾回收器調(diào)用此方法。

（4）Class<? extendsObject> getClass()--->返回一個對象的運行時類。

（5）int hashCode()--->返回該對象的哈希碼值。

（6）void notify()--->喚醒在此對象監(jiān)視器上等待的單個線程。

（7）void notifyAll()--->喚醒在此對象監(jiān)視器上等待的所有線程。

（8）String toString()--->返回該對象的字符串表示。

（9）void wait()--->導致當前的線程等待，直到其他線程調(diào)用此對象的 notify() 方法或 notifyAll() 方法。

void wait(long timeout)--->導致當前的線程等待，直到其他線程調(diào)用此對象的 notify() 方法或 notifyAll()方法，或者超過指定的時間量。

void wait(long timeout, int nanos)--->導致當前的線程等待，直到其他線程調(diào)用此對象的 notify()

13、集合框架簡單體系圖

14、ArrayList、LinkedList、Vector的區(qū)別？

ArrayList,LinkedList和Vector都繼承自List接口。

ArrayList和Vector的底層是動態(tài)數(shù)組，LinkedList的底層是雙向鏈表.

ArrayList和Vector的區(qū)別就是ArrayList是線程不安全的，Vector是線程安全的，Vector中的方法都是同步方法(synchronized),所以ArrayList的執(zhí)行效率要高于Vector,它也是用的最廣泛的一種集合。

我們重點比較一下ArrayList和LinkedList的區(qū)別，其實ArrayList和LinkedList之間的區(qū)別就是數(shù)組和雙向鏈表之間的區(qū)別。

數(shù)組的特點：因為數(shù)組分配的是一塊連續(xù)的內(nèi)存空間，使用索引來查找元素是非?？焖俚?。但是插入，刪除數(shù)據(jù)性能比較低。

雙向鏈表的特點，查詢效率較低，因為查詢一個元素需要從頭部或尾部開始查詢，挨個遍歷每一個元素直到找到所需元素，插入，刪除效率高比如我們刪掉一個元素直接把它前一個元素的指針指向它后一個元素就可以了

15、HashMap源碼分析？

先來看一下添加元素的過程，然后再看擴容方法。

首先要思考一個問題，既然HashMap是用數(shù)組來存數(shù)據(jù)的，而數(shù)組的類型是一個Node節(jié)點，而節(jié)點中如果只放key和value，每次添加的時候就去循環(huán)數(shù)組判斷是否有同樣的key，如果沒有則添加，有就覆蓋，然后每次根據(jù)key取值的時候也循環(huán)數(shù)組判斷是否存在該key然后取出對應的value，那么可想而知，當數(shù)組中的元素量變成10、100、1000甚至成百上千萬的時候，執(zhí)行效率會有多低。

(1) 所以我們能想到的，HashMap也能想到，而HashMap是怎么解決這一個問題的呢？

答案是，HashMap會根據(jù)不同的key計算出數(shù)組下標，然后直接把該key存到指定的下標位置上，取的時候也是通過該key計算出位置，直接通過下標位置在數(shù)組上取，這樣就不需要去循環(huán)判斷取數(shù)據(jù)了，完美解決上面說到的問題。我們接著看HashMap是同通過什么樣的方式計算出位置呢？

(2)首先我們了解一下Hash是什么?

Hash，一般翻譯做散列、雜湊，或音譯為哈希，是把任意長度的輸入通過散列算法變換成固定長度的輸出，該輸出就是散列值。這種轉(zhuǎn)換是一種壓縮映射，也就是，散列值的空間通常遠小于輸入的空間，不同的輸入可能會散列成相同的輸出，所以不可能從散列值來確定唯一的輸入值。簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數(shù)。對不同的關鍵字可能得到同一散列地址，即key1≠key2，而key1的哈希值=key2的哈希值，這種現(xiàn)象稱碰撞。（但碰撞的概率是很小的）

(3)所以HashMap會先獲取到key的哈希值，但是假設當前數(shù)組長度16，獲取到了hash值之后怎樣才能得到獲取存儲的數(shù)組下標，并且讓下標在0~15之中呢？（肯定不能越界對吧）

答案是這樣的，我們都知道一個k1取模k2，結(jié)果肯定不會大于k2對吧，而且結(jié)果肯定在0~k2之中，所以HashMap就是這樣來確定下標位置的，不過是用的另外一種方式計算，就是：(len - 1) & hash，通過按位與的方式也能達到取模的效果，而且計算速度更快。好了，先小小總結(jié)一下，HashMap首先根據(jù)key值獲取到hash值，然后根據(jù)hash值獲取到存放的數(shù)組位置，但是接下來又有一個問題了。

(4)如果hash發(fā)生了碰撞，就是不同的key但得到了同一個hash值，結(jié)果獲得的數(shù)組位置也是同一個，本來同一個key是可以直接覆蓋的（因為hashmap本來就不能存相同的key），可是這兩個key又不是同一個，肯定不能覆蓋，那應該怎么辦呢？

所以，HashMap就加入了鏈表，當計算出key位置之后，發(fā)現(xiàn)該位置上已經(jīng)有一個元素了，然后就進行判斷，如果我這個key的值和已經(jīng)存在的key值不相等，然后就往改元素后面添加，也就是通過Node節(jié)點指向下一個Node節(jié)點，此時該數(shù)組位置上就有一個包含兩個node節(jié)點的鏈表了。等于當添加元素的時候，發(fā)現(xiàn)該數(shù)組位置上已經(jīng)有值了，并且當前key值與鏈表中的所有key都不相等，就往這個鏈表中追加?？墒乾F(xiàn)在又有了一個新的問題，一旦某一個數(shù)組位置上鏈表的長度越來越長之后，是不是又回到了當初說循環(huán)判斷key值，會影響的效率問題（雖然不是每次存取元素都要循環(huán)，但還是可以優(yōu)化呀），所以jdk1.8做了進一步的優(yōu)化。

所以就增加了紅黑樹的概念，當鏈表中的長度為9的時候就轉(zhuǎn)為紅黑樹，使用紅黑樹結(jié)構(gòu)可以優(yōu)化計算機的處理過程，使得進一步的提升了極端情況下的性能。（有部分博客可能沒有把最初的那個node節(jié)點計算進來，寫著當有8次碰撞的時候轉(zhuǎn)紅黑樹，導致有些人認為鏈表中長度為8的時候轉(zhuǎn)紅黑樹

16、HashMap在JDK1.7和1.8中的區(qū)別？

1.最重要的一點是底層結(jié)構(gòu)不一樣，1.7是數(shù)組+鏈表，1.8則是數(shù)組+鏈表+紅黑樹結(jié)構(gòu);

2.jdk1.7中當哈希表為空時，會先調(diào)用inflateTable()初始化一個數(shù)組；而1.8則是直接調(diào)用resize()擴容;

3.插入鍵值對的put方法的區(qū)別，1.8中會將節(jié)點插入到鏈表尾部，而1.7中是采用頭插；

4.jdk1.7中的hash函數(shù)對哈希值的計算直接使用key的hashCode值，而1.8中則是采用key的hashCode異或上key的hashCode進行無符號右移16位的結(jié)果，避免了只靠低位數(shù)據(jù)來計算哈希時導致的沖突，計算結(jié)果由高低位結(jié)合決定，使元素分布更均勻；

5.擴容時1.8會保持原鏈表的順序，而1.7會顛倒鏈表的順序；而且1.8是在元素插入后檢測是否需要擴容，1.7則是在元素插入前；

6.jdk1.8是擴容時通過hash&cap==0將鏈表分散，無需改變hash值，而1.7是通過更新hashSeed來修改hash值達到分散的目的；

7.擴容策略：1.7中是只要不小于閾值就直接擴容2倍；而1.8的擴容策略會更優(yōu)化，當數(shù)組容量未達到64時，以2倍進行擴容，超過64之后若桶中元素個數(shù)不小于7就將鏈表轉(zhuǎn)換為紅黑樹，但如果紅黑樹中的元素個數(shù)小于6就會還原為鏈表，當紅黑樹中元素不小于32的時候才會再次擴容。

總結(jié)

本篇文章就到這里了，希望能對幫助到你，也希望你能夠多多關注腳本之家的更多內(nèi)容！