更新時間:2019-08-23 14:21:40 來源:動力節(jié)點 瀏覽2850次
List和Set的區(qū)別
List,Set都是繼承自Collection接口List特點:元素有放入順序,元素可重復(fù),Set特點:元素無放入順序,元素不可重復(fù),重復(fù)元素會覆蓋掉,(元素雖然無放入順序,但是元素在set中的位置是有該元素的HashCode決定的,其位置其實是固定的,加入Set的Object必須定義equals()方法,另外list支持for循環(huán),也就是通過下標來遍歷,也可以用迭代器,但是set只能用迭代,因為他無序,無法用下標來取得想要的值。)Set和List對比Set:檢索元素效率低下,刪除和插入效率高,插入和刪除不會引起元素位置改變。
List:和數(shù)組類似,List可以動態(tài)增長,查找元素效率高,插入刪除元素效率低,因為會引起其他元素位置改變
HashSet是如何保證不重復(fù)的
向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的代碼中。假設(shè)一種情況,線程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ù)。
Java反射機制
Java反射機制是在運行狀態(tài)中,對于任意一個類,都能夠獲得這個類的所有屬性和方法,對于任意一個對象都能夠調(diào)用它的任意一個屬性和方法。這種在運行時動態(tài)的獲取信息以及動態(tài)調(diào)用對象的方法的功能稱為Java的反射機制。
Class類與java.lang.reflect類庫一起對反射的概念進行了支持,該類庫包含了Field,Method,Constructor類(每個類都實現(xiàn)了Member接口)。這些類型的對象時由JVM在運行時創(chuàng)建的,用以表示未知類里對應(yīng)的成員。
這樣你就可以使用Constructor創(chuàng)建新的對象,用get()和set()方法讀取和修改與Field對象關(guān)聯(lián)的字段,用invoke()方法調(diào)用與Method對象關(guān)聯(lián)的方法。另外,還可以調(diào)用getFields()getMethods()和getConstructors()等很便利的方法,以返回表示字段,方法,以及構(gòu)造器的對象的數(shù)組。這樣匿名對象的信息就能在運行時被完全確定下來,而在編譯時不需要知道任何事情。
運行結(jié)果:無參構(gòu)造器Run………..有參構(gòu)造器Run………..Apple
異常分類以及處理機制
Java標準庫內(nèi)建了一些通用的異常,這些類以Throwable為頂層父類。
Throwable又派生出Error類和Exception類。
錯誤:Error類以及他的子類的實例,代表了JVM本身的錯誤。錯誤不能被程序員通過代碼處理,Error很少出現(xiàn)。
因此,程序員應(yīng)該關(guān)注Exception為父類的分支下的各種異常類。
異常:Exception以及他的子類,代表程序運行時發(fā)送的各種不期望發(fā)生的事件。可以被Java異常處理機制使用,是異常處理的核心。
總體上我們根據(jù)Javac對異常的處理要求,將異常類分為二類。
非檢查異常(unckeckedexception):Error和RuntimeException以及他們的子類。javac在編譯時,不會提示和發(fā)現(xiàn)這樣的異常,不要求在程序處理這些異常。所以如果愿意,我們可以編寫代碼處理(使用try…catch…finally)這樣的異常,也可以不處理。對于這些異常,我們應(yīng)該修正代碼,而不是去通過異常處理器處理。這樣的異常發(fā)生的原因多半是代碼寫的有問題。如除0錯誤ArithmeticException,錯誤的強制類型轉(zhuǎn)換錯誤ClassCastException,數(shù)組索引越界ArrayIndexOutOfBoundsException,使用了空對象NullPointerException等等。
檢查異常(checkedexception):除了Error和RuntimeException的其它異常。javac強制要求程序員為這樣的異常做預(yù)備處理工作(使用try…catch…finally或者throws)。在方法中要么用try-catch語句捕獲它并處理,要么用throws子句聲明拋出它,否則編譯不會通過。這樣的異常一般是由程序的運行環(huán)境導致的。因為程序可能被運行在各種未知的環(huán)境下,而程序員無法干預(yù)用戶如何使用他編寫的程序,于是程序員就應(yīng)該為這樣的異常時刻準備著。如SQLException,IOException,ClassNotFoundException等。
需要明確的是:檢查和非檢查是對于javac來說的,這樣就很好理解和區(qū)分了。