List和Set的區(qū)別

　　List,Set都是繼承自Collection接口List特點：元素有放入順序，元素可重復，Set特點：元素無放入順序，元素不可重復，重復元素會覆蓋掉，（元素雖然無放入順序，但是元素在set中的位置是有該元素的HashCode決定的，其位置其實是固定的，加入Set的Object必須定義equals()方法，另外list支持for循環(huán)，也就是通過下標來遍歷，也可以用迭代器，但是set只能用迭代，因為他無序，無法用下標來取得想要的值。）Set和List對比Set：檢索元素效率低下，刪除和插入效率高，插入和刪除不會引起元素位置改變。

　　List：和數(shù)組類似，List可以動態(tài)增長，查找元素效率高，插入刪除元素效率低，因為會引起其他元素位置改變

　　HashSet是如何保證不重復的

　　向HashSet中add()元素時，判斷元素是否存在的依據(jù)，不僅要比較hash值，同時還要結(jié)合equles方法比較。

　　HashSet中的add()方法會使用HashMap的add()方法。以下是HashSet部分源碼：

　　HashMap是線程安全的嗎，為什么不是線程安全的（最好畫圖說明多線程環(huán)境下不安全）?

　　不是線程安全的；如果有兩個線程A和B，都進行插入數(shù)據(jù)，剛好這兩條不同的數(shù)據(jù)經(jīng)過哈希計算后得到的哈希碼是一樣的，且該位置還沒有其他的數(shù)據(jù)。所以這兩個線程都會進入我在上面標記為1的代碼中。假設一種情況，線程A通過if判斷，該位置沒有哈希沖突，進入了if語句，還沒有進行數(shù)據(jù)插入，這時候CPU就把資源讓給了線程B，線程A停在了if語句里面，線程B判斷該位置沒有哈希沖突（線程A的數(shù)據(jù)還沒插入），也進入了if語句，線程B執(zhí)行完后，輪到線程A執(zhí)行，現(xiàn)在線程A直接在該位置插入而不用再判斷。這時候，你會發(fā)現(xiàn)線程A把線程B插入的數(shù)據(jù)給覆蓋了。發(fā)生了線程不安全情況。本來在HashMap中，發(fā)生哈希沖突是可以用鏈表法或者紅黑樹來解決的，但是在多線程中，可能就直接給覆蓋了。

　　上面所說的是一個圖來解釋可能更加直觀。如下面所示，兩個線程在同一個位置添加數(shù)據(jù)，后面添加的數(shù)據(jù)就覆蓋住了前面添加的。

　　如果上述插入是插入到鏈表上，如兩個線程都在遍歷到最后一個節(jié)點，都要在最后添加一個數(shù)據(jù)，那么后面添加數(shù)劇的線程就會把前面添加的數(shù)據(jù)給覆蓋住。

　　則在擴容的時候也可能會導致數(shù)據(jù)不一致，因為擴容是從一個數(shù)組拷貝到另外一個數(shù)組。

　　HashMap的擴容過程

　　當向容器添加元素的時候，會判斷當前容器的元素個數(shù)，如果大于等于閾值(知道這個閾字怎么念嗎？不念fa值，念yu值四聲)---即當前數(shù)組的長度乘以加載因子的值的時候，就要自動擴容啦。

　　擴容(resize)就是重新計算容量，向HashMap對象里不停的添加元素，而HashMap對象內(nèi)部的數(shù)組無法裝載更多的元素時，對象就需要擴大數(shù)組的長度，以便能裝入更多的元素。當然Java里的數(shù)組是無法自動擴容的，方法是使用一個新的數(shù)組代替已有的容量小的數(shù)組，就像我們用一個小桶裝水，如果想裝更多的水，就得換大水桶。

　　如果cap是2的n次方，則容量為cap，否則為大于cap的第一個2的n次方的數(shù)。

　　HashMap1.7與1.8的區(qū)別，說明1.8做了哪些優(yōu)化，如何優(yōu)化的？

　　HashMap結(jié)構(gòu)圖

　　在JDK1.7及之前的版本中，HashMap又叫散列鏈表：基于一個數(shù)組以及多個鏈表的實現(xiàn)，hash值沖突的時候，就將對應節(jié)點以鏈表的形式存儲。

　　JDK1.8中，當同一個hash值（Table上元素）的鏈表節(jié)點數(shù)不小于8時，將不再以單鏈表的形式存儲了，會被調(diào)整成一顆紅黑樹。這就是JDK7與JDK8中HashMap實現(xiàn)的最大區(qū)別。

　　其下基于JDK1.7.0_80與JDK1.8.0_66做的分析

　　JDK1.7中

　　使用一個Entry數(shù)組來存儲數(shù)據(jù)，用key的hashcode取模來決定key會被放到數(shù)組里的位置，如果hashcode相同，或者hashcode取模后的結(jié)果相同（hashcollision），那么這些key會被定位到Entry數(shù)組的同一個格子里，這些key會形成一個鏈表。

　　在hashcode特別差的情況下，比方說所有key的hashcode都相同，這個鏈表可能會很長，那么put/get操作都可能需要遍歷這個鏈表，也就是說時間復雜度在最差情況下會退化到O(n)

　　JDK1.8中

　　使用一個Node數(shù)組來存儲數(shù)據(jù)，但這個Node可能是鏈表結(jié)構(gòu)，也可能是紅黑樹結(jié)構(gòu)

　　如果插入的key的hashcode相同，那么這些key也會被定位到Node數(shù)組的同一個格子里。

　　如果同一個格子里的key不超過8個，使用鏈表結(jié)構(gòu)存儲。

　　如果超過了8個，那么會調(diào)用treeifyBin函數(shù)，將鏈表轉(zhuǎn)換為紅黑樹。

　　那么即使hashcode完全相同，由于紅黑樹的特點，查找某個特定元素，也只需要O(logn)的開銷也就是說put/get的操作的時間復雜度最差只有O(logn)聽起來挺不錯，但是真正想要利用JDK1.8的好處，有一個限制：

　　key的對象，必須正確的實現(xiàn)了Compare接口如果沒有實現(xiàn)Compare接口，或者實現(xiàn)得不正確（比方說所有Compare方法都返回0）那JDK1.8的HashMap其實還是慢于JDK1.7的

　　簡單的測試數(shù)據(jù)如下：

　　向HashMap中put/get1w條hashcode相同的對象

　　JDK1.7:put0.26s，get0.55s

　　JDK1.8（未實現(xiàn)Compare接口）：put0.92s，get2.1s

　　但是如果正確的實現(xiàn)了Compare接口，那么JDK1.8中的HashMap的性能有巨大提升，這次put/get100W條hashcode相同的對象

　　JDK1.8（正確實現(xiàn)Compare接口，）：put/get大概開銷都在320ms左右

　　finalfinallyfinalizefinal

　　可以修飾類、變量、方法，修飾類表示該類不能被繼承、修飾方法表示該方法不能被重寫、修飾變量表示該變量是一個常量不能被重新賦值。

　　finally一般作用在try-catch代碼塊中，在處理異常的時候，通常我們將一定要執(zhí)行的代碼方法finally代碼塊中，表示不管是否出現(xiàn)異常，該代碼塊都會執(zhí)行，一般用來存放一些關(guān)閉資源的代碼。

　　finalize是一個方法，屬于Object類的一個方法，而Object類是所有類的父類，該方法一般由垃圾回收器來調(diào)用，當我們調(diào)用System.gc()方法的時候，由垃圾回收器調(diào)用finalize()，回收垃圾，一個對象是否可回收的最后判斷。

       以上就是動力節(jié)點Java培訓機構(gòu)小編介紹的“大型互聯(lián)網(wǎng)絡企業(yè)Java面試題”的內(nèi)容，希望對大家有幫助，如有疑問，請在線咨詢，有專業(yè)老師隨時為你服務。

相關(guān)推薦

最新最全java面試題及答案（初級到高級）

史上最全的中高級JAVA工程師面試題及答案匯總

Java高級開發(fā)工程師面試題

2019史上最全java面試題題庫大全800題

哪有資深java工程師面試題