Java集合詳解2:LinkedList和Queue

今天咱們來探索一下LIterator,fail-fast機制與比較器的源碼。java

具體代碼在個人GitHub中能夠找到git

https://github.com/h2pl/MyTech程序員

喜歡的話麻煩star一下哈github

文章首發於個人我的博客:後端

https://h2pl.github.io/2018/05/9/collection3設計模式

更多關於Java後端學習的內容請到個人CSDN博客上查看:https://blog.csdn.net/a724888數組

個人我的博客主要發原創文章,也歡迎瀏覽 https://h2pl.github.io/安全

Iterator

本文參考 http://cmsblogs.com/?p=1185微信

迭代對於咱們搞Java的來講絕對不陌生。咱們經常使用JDK提供的迭代接口進行Java集合的迭代。網絡

Iterator iterator = list.iterator();
        while(iterator.hasNext()){
            String string = iterator.next();
            //do something
        }

迭代其實咱們能夠簡單地理解爲遍歷,是一個標準化遍歷各種容器裏面的全部對象的方法類,它是一個很典型的設計模式。Iterator模式是用於遍歷集合類的標準訪問方法。

它能夠把訪問邏輯從不一樣類型的集合類中抽象出來,從而避免向客戶端暴露集合的內部結構。 在沒有迭代器時咱們都是這麼進行處理的。以下:

對於數組咱們是使用下標來進行處理的:

int[] arrays = new int[10];
   for(int i = 0 ; i < arrays.length ; i++){
       int a = arrays[i];
       //do something
   }

對於ArrayList是這麼處理的:

List<String> list = new ArrayList<String>();
   for(int i = 0 ; i < list.size() ;  i++){
      String string = list.get(i);
      //do something
   }

對於這兩種方式,咱們老是都事先知道集合的內部結構,訪問代碼和集合自己是緊密耦合的,沒法將訪問邏輯從集合類和客戶端代碼中分離出來。同時每一種集合對應一種遍歷方法,客戶端代碼沒法複用。

在實際應用中如何須要將上面將兩個集合進行整合是至關麻煩的。因此爲了解決以上問題,Iterator模式騰空出世,它老是用同一種邏輯來遍歷集合。

使得客戶端自身不須要來維護集合的內部結構,全部的內部狀態都由Iterator來維護。客戶端從不直接和集合類打交道,它老是控制Iterator,向它發送"向前","向後","取當前元素"的命令,就能夠間接遍歷整個集合。

上面只是對Iterator模式進行簡單的說明,下面咱們看看Java中Iterator接口,看他是如何來進行實現的。

java.util.Iterator

在Java中Iterator爲一個接口,它只提供了迭代了基本規則,在JDK中他是這樣定義的:對 collection 進行迭代的迭代器。迭代器取代了 Java Collections Framework 中的 Enumeration。迭代器與枚舉有兩點不一樣:

一、迭代器容許調用者利用定義良好的語義在迭代期間從迭代器所指向的 collection 移除元素。

二、方法名稱獲得了改進。

其接口定義以下:

public interface Iterator {
&emsp;&emsp;boolean hasNext();
&emsp;&emsp;Object next();
&emsp;&emsp;void remove();
}

其中:

Object next():返回迭代器剛越過的元素的引用,返回值是Object,須要強制轉換成本身須要的類型

boolean hasNext():判斷容器內是否還有可供訪問的元素

void remove():刪除迭代器剛越過的元素

對於咱們而言,咱們只通常只需使用next()、hasNext()兩個方法便可完成迭代。以下:

for(Iterator it = c.iterator(); it.hasNext(); ) {
&emsp;&emsp;Object o = it.next();
&emsp;&emsp; //do something
}

==前面闡述了Iterator有一個很大的優勢,就是咱們沒必要知道集合的內部結果,集合的內部結構、狀態由Iterator來維持,經過統一的方法hasNext()、next()來判斷、獲取下一個元素,至於具體的內部實現咱們就不用關心了。==

可是做爲一個合格的程序員咱們很是有必要來弄清楚Iterator的實現。下面就ArrayList的源碼進行分析分析。

各個集合的Iterator的實現

下面就ArrayList的Iterator實現來分析,其實若是咱們理解了ArrayList、Hashset、TreeSet的數據結構,內部實現,對於他們是如何實現Iterator也會成竹在胸的。由於ArrayList的內部實現採用數組,因此咱們只須要記錄相應位置的索引便可,其方法的實現比較簡單。

ArrayList的Iterator實現

在ArrayList內部首先是定義一個內部類Itr,該內部類實現Iterator接口,以下:

private class Itr implements Iterator<E> {
    //do something
}
而ArrayList的iterator()方法實現:

public Iterator<E> iterator() {
        return new Itr();
    }

因此經過使用ArrayList.iterator()方法返回的是Itr()內部類,因此如今咱們須要關心的就是Itr()內部類的實現:

在Itr內部定義了三個int型的變量:cursor、lastRet、expectedModCount。其中cursor表示下一個元素的索引位置,lastRet表示上一個元素的索引位置

int cursor;             
        int lastRet = -1;     
        int expectedModCount = modCount;

從cursor、lastRet定義能夠看出,lastRet一直比cursor少一因此hasNext()實現方法異常簡單,只須要判斷cursor和lastRet是否相等便可。

public boolean hasNext() {
    return cursor != size;
}

對於next()實現其實也是比較簡單的,只要返回cursor索引位置處的元素便可,而後修改cursor、lastRet便可。

public E next() {
    checkForComodification();
    int i = cursor;    //記錄索引位置
    if (i >= size)    //若是獲取元素大於集合元素個數,則拋出異常
        throw new NoSuchElementException();
    Object[] elementData = ArrayList.this.elementData;
    if (i >= elementData.length)
        throw new ConcurrentModificationException();
    cursor = i + 1;      //cursor + 1
    return (E) elementData[lastRet = i];  //lastRet + 1 且返回cursor處元素
}

checkForComodification()主要用來判斷集合的修改次數是否合法,即用來判斷遍歷過程當中集合是否被修改過。

。modCount用於記錄ArrayList集合的修改次數,初始化爲0,,每當集合被修改一次(結構上面的修改,內部update不算),如add、remove等方法,modCount + 1,因此若是modCount不變,則表示集合內容沒有被修改。

該機制主要是用於實現ArrayList集合的快速失敗機制,在Java的集合中,較大一部分集合是存在快速失敗機制的,這裏就很少說,後面會講到。

因此要保證在遍歷過程當中不出錯誤,咱們就應該保證在遍歷過程當中不會對集合產生結構上的修改(固然remove方法除外),出現了異常錯誤,咱們就應該認真檢查程序是否出錯而不是catch後不作處理。

final void checkForComodification() {
            if (modCount != expectedModCount)
                throw new ConcurrentModificationException();
        }
對於remove()方法的是實現,它是調用ArrayList自己的remove()方法刪除lastRet位置元素,而後修改modCount便可。

public void remove() {
    if (lastRet < 0)
        throw new IllegalStateException();
    checkForComodification();

    try {
        ArrayList.this.remove(lastRet);
        cursor = lastRet;
        lastRet = -1;
        expectedModCount = modCount;
    } catch (IndexOutOfBoundsException ex) {
        throw new ConcurrentModificationException();
    }
}

這裏就對ArrayList的Iterator實現講解到這裏,對於Hashset、TreeSet等集合的Iterator實現,各位若是感興趣能夠繼續研究,我的認爲在研究這些集合的源碼以前,有必要對該集合的數據結構有清晰的認識,這樣會達到事半功倍的效果!!!!

fail-fast機制

這部分參考http://cmsblogs.com/?p=1220

在JDK的Collection中咱們時常會看到相似於這樣的話:

例如,ArrayList:

注意,迭代器的快速失敗行爲沒法獲得保證,由於通常來講,不可能對是否出現不一樣步併發修改作出任何硬性保證。快速失敗迭代器會盡最大努力拋出ConcurrentModificationException。 所以,爲提升這類迭代器的正確性而編寫一個依賴於此異常的程序是錯誤的作法:迭代器的快速失敗行爲應該僅用於檢測 bug。

HashMap中:

注意,迭代器的快速失敗行爲不能獲得保證,通常來講,存在非同步的併發修改時,不可能做出任何堅定的保證。快速失敗迭代器盡最大努力拋出 ConcurrentModificationException。所以,編寫依賴於此異常的程序的作法是錯誤的,正確作法是:迭代器的快速失敗行爲應該僅用於檢測程序錯誤。

在這兩段話中反覆地提到」快速失敗」。那麼何爲」快速失敗」機制呢?

「快速失敗」也就是fail-fast,它是Java集合的一種錯誤檢測機制。當多個線程對集合進行結構上的改變的操做時,有可能會產生fail-fast機制。

記住是有可能,而不是必定。例如:假設存在兩個線程(線程一、線程2),線程1經過Iterator在遍歷集合A中的元素,在某個時候線程2修改了集合A的結構(是結構上面的修改,而不是簡單的修改集合元素的內容),那麼這個時候程序就會拋出 ConcurrentModificationException異常,從而產生fail-fast機制。

fail-fast示例

public class FailFastTest {
    private static List<Integer> list = new ArrayList<>();
    
    /**
     * @desc:線程one迭代list
     * @Project:test
     * @file:FailFastTest.java
     * @Authro:chenssy
     * @data:2014年7月26日
     */
    private static class threadOne extends Thread{
        public void run() {
            Iterator<Integer> iterator = list.iterator();
            while(iterator.hasNext()){
                int i = iterator.next();
                System.out.println("ThreadOne 遍歷:" + i);
                try {
                    Thread.sleep(10);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }
    
    /**
     * @desc:當i == 3時,修改list
     * @Project:test
     * @file:FailFastTest.java
     * @Authro:chenssy
     * @data:2014年7月26日
     */
    private static class threadTwo extends Thread{
        public void run(){
            int i = 0 ; 
            while(i < 6){
                System.out.println("ThreadTwo run:" + i);
                if(i == 3){
                    list.remove(i);
                }
                i++;
            }
        }
    }
    
    public static void main(String[] args) {
        for(int i = 0 ; i < 10;i++){
            list.add(i);
        }
        new threadOne().start();
        new threadTwo().start();
    }
}

運行結果:

ThreadOne 遍歷:0
ThreadTwo run:0
ThreadTwo run:1
ThreadTwo run:2
ThreadTwo run:3
ThreadTwo run:4
ThreadTwo run:5
Exception in thread "Thread-0" java.util.ConcurrentModificationException
    at java.util.ArrayList$Itr.checkForComodification(Unknown Source)
    at java.util.ArrayList$Itr.next(Unknown Source)
    at test.ArrayListTest$threadOne.run(ArrayListTest.java:23)

fail-fast產生緣由

經過上面的示例和講解,我初步知道fail-fast產生的緣由就在於程序在對 collection 進行迭代時,某個線程對該 collection 在結構上對其作了修改,這時迭代器就會拋出 ConcurrentModificationException 異常信息,從而產生 fail-fast。

要了解fail-fast機制,咱們首先要對ConcurrentModificationException 異常有所瞭解。當方法檢測到對象的併發修改,但不容許這種修改時就拋出該異常。同時須要注意的是,該異常不會始終指出對象已經由不一樣線程併發修改,若是單線程違反了規則,一樣也有可能會拋出改異常。

誠然,迭代器的快速失敗行爲沒法獲得保證,它不能保證必定會出現該錯誤,可是快速失敗操做會盡最大努力拋出ConcurrentModificationException異常,因此所以,爲提升此類操做的正確性而編寫一個依賴於此異常的程序是錯誤的作法,正確作法是:ConcurrentModificationException 應該僅用於檢測 bug。下面我將以ArrayList爲例進一步分析fail-fast產生的緣由。

從前面咱們知道fail-fast是在操做迭代器時產生的。如今咱們來看看ArrayList中迭代器的源代碼:

private class Itr implements Iterator<E> {
        int cursor;
        int lastRet = -1;
        int expectedModCount = ArrayList.this.modCount;

        public boolean hasNext() {
            return (this.cursor != ArrayList.this.size);
        }

        public E next() {
            checkForComodification();
            /** 省略此處代碼 */
        }

        public void remove() {
            if (this.lastRet < 0)
                throw new IllegalStateException();
            checkForComodification();
            /** 省略此處代碼 */
        }

        final void checkForComodification() {
            if (ArrayList.this.modCount == this.expectedModCount)
                return;
            throw new ConcurrentModificationException();
        }
    }

從上面的源代碼咱們能夠看出,迭代器在調用next()、remove()方法時都是調用checkForComodification()方法,該方法主要就是檢測modCount == expectedModCount ? 若不等則拋出ConcurrentModificationException 異常,從而產生fail-fast機制。因此要弄清楚爲何會產生fail-fast機制咱們就必需要用弄明白爲何modCount != expectedModCount ,他們的值在何時發生改變的。

expectedModCount 是在Itr中定義的:int expectedModCount = ArrayList.this.modCount;因此他的值是不可能會修改的,因此會變的就是modCount。modCount是在 AbstractList 中定義的,爲全局變量:

protected transient int modCount = 0; 那麼他何時由於什麼緣由而發生改變呢?請看ArrayList的源碼:

public boolean add(E paramE) {
    ensureCapacityInternal(this.size + 1);
    /** 省略此處代碼 */
}

private void ensureCapacityInternal(int paramInt) {
    if (this.elementData == EMPTY_ELEMENTDATA)
        paramInt = Math.max(10, paramInt);
    ensureExplicitCapacity(paramInt);
}

private void ensureExplicitCapacity(int paramInt) {
    this.modCount += 1;    //修改modCount
    /** 省略此處代碼 */
}

public boolean remove(Object paramObject) { int i; if (paramObject == null) for (i = 0; i < this.size; ++i) { if (this.elementData[i] != null) continue; fastRemove(i); return true; } else for (i = 0; i < this.size; ++i) { if (!(paramObject.equals(this.elementData[i]))) continue; fastRemove(i); return true; } return false; }

private void fastRemove(int paramInt) {
    this.modCount += 1;   //修改modCount
    /** 省略此處代碼 */
}

public void clear() {
    this.modCount += 1;    //修改modCount
    /** 省略此處代碼 */
}

從上面的源代碼咱們能夠看出,ArrayList中不管add、remove、clear方法只要是涉及了改變ArrayList元素的個數的方法都會致使modCount的改變。

因此咱們這裏能夠初步判斷因爲expectedModCount 得值與modCount的改變不一樣步,致使二者之間不等從而產生fail-fast機制。知道產生fail-fast產生的根本緣由了,咱們能夠有以下場景:

有兩個線程(線程A,線程B),其中線程A負責遍歷list、線程B修改list。線程A在遍歷list過程的某個時候(此時expectedModCount = modCount=N),線程啓動,同時線程B增長一個元素,這是modCount的值發生改變(modCount + 1 = N + 1)。

線程A繼續遍歷執行next方法時,通告checkForComodification方法發現expectedModCount = N ,而modCount = N + 1,二者不等,這時就拋出ConcurrentModificationException 異常,從而產生fail-fast機制。

因此,直到這裏咱們已經徹底瞭解了fail-fast產生的根本緣由了。知道了緣由就好找解決辦法了。

3、fail-fast解決辦法

經過前面的實例、源碼分析,我想各位已經基本瞭解了fail-fast的機制,下面我就產生的緣由提出解決方案。這裏有兩種解決方案:

方案一:在遍歷過程當中全部涉及到改變modCount值得地方所有加上synchronized或者直接使用Collections.synchronizedList,這樣就能夠解決。可是不推薦,由於增刪形成的同步鎖可能會阻塞遍歷操做。

方案二:使用CopyOnWriteArrayList來替換ArrayList。推薦使用該方案。

CopyOnWriteArrayList爲什麼物?ArrayList 的一個線程安全的變體,其中全部可變操做(add、set 等等)都是經過對底層數組進行一次新的複製來實現的。 該類產生的開銷比較大,可是在兩種狀況下,它很是適合使用。

1:在不能或不想進行同步遍歷,但又須要從併發線程中排除衝突時。

2:當遍歷操做的數量大大超過可變操做的數量時。遇到這兩種狀況使用CopyOnWriteArrayList來替代ArrayList再適合不過了。那麼爲何CopyOnWriterArrayList能夠替代ArrayList呢?

第1、CopyOnWriterArrayList的不管是從數據結構、定義都和ArrayList同樣。它和ArrayList同樣,一樣是實現List接口,底層使用數組實現。在方法上也包含add、remove、clear、iterator等方法。

第2、CopyOnWriterArrayList根本就不會產生ConcurrentModificationException異常,也就是它使用迭代器徹底不會產生fail-fast機制。請看:

private static class COWIterator implements ListIterator { /** 省略此處代碼 */ public E next() { if (!(hasNext())) throw new NoSuchElementException(); return this.snapshot[(this.cursor++)]; }

/** 省略此處代碼 */
}

CopyOnWriterArrayList的方法根本就沒有像ArrayList中使用checkForComodification方法來判斷expectedModCount 與 modCount 是否相等。它爲何會這麼作,憑什麼能夠這麼作呢?咱們以add方法爲例:

public boolean add(E paramE) {
        ReentrantLock localReentrantLock = this.lock;
        localReentrantLock.lock();
        try {
            Object[] arrayOfObject1 = getArray();
            int i = arrayOfObject1.length;
            Object[] arrayOfObject2 = Arrays.copyOf(arrayOfObject1, i + 1);
            arrayOfObject2[i] = paramE;
            setArray(arrayOfObject2);
            int j = 1;
            return j;
        } finally {
            localReentrantLock.unlock();
        }
    }

    
    final void setArray(Object[] paramArrayOfObject) {
        this.array = paramArrayOfObject;
    }

CopyOnWriterArrayList的add方法與ArrayList的add方法有一個最大的不一樣點就在於,下面三句代碼:

Object[] arrayOfObject2 = Arrays.copyOf(arrayOfObject1, i + 1);
arrayOfObject2[i] = paramE;
setArray(arrayOfObject2);

就是這三句代碼使得CopyOnWriterArrayList不會拋ConcurrentModificationException異常。他們所展示的魅力就在於copy原來的array,再在copy數組上進行add操做,這樣作就徹底不會影響COWIterator中的array了。

因此CopyOnWriterArrayList所表明的核心概念就是:任何對array在結構上有所改變的操做(add、remove、clear等),CopyOnWriterArrayList都會copy現有的數據,再在copy的數據上修改,這樣就不會影響COWIterator中的數據了,修改完成以後改變原有數據的引用便可。同時這樣形成的代價就是產生大量的對象,同時數組的copy也是至關有損耗的。

Comparable 和 Comparator

Java 中爲咱們提供了兩種比較機制:Comparable 和 Comparator,他們之間有什麼區別呢?今天來了解一下。

Comparable

Comparable 在 java.lang包下,是一個接口,內部只有一個方法 compareTo():

public interface Comparable<T> {
    public int compareTo(T o);
}

Comparable 可讓實現它的類的對象進行比較,具體的比較規則是按照 compareTo 方法中的規則進行。這種順序稱爲 天然順序。

compareTo 方法的返回值有三種狀況:

e1.compareTo(e2) > 0 即 e1 > e2
e1.compareTo(e2) = 0 即 e1 = e2
e1.compareTo(e2) < 0 即 e1 < e2

注意:

1.因爲 null 不是一個類,也不是一個對象,所以在重寫 compareTo 方法時應該注意 e.compareTo(null) 的狀況,即便 e.equals(null) 返回 false,compareTo 方法也應該主動拋出一個空指針異常 NullPointerException。

2.Comparable 實現類重寫 compareTo 方法時通常要求 e1.compareTo(e2) == 0 的結果要和 e1.equals(e2) 一致。這樣未來使用 SortedSet 等根據類的天然排序進行排序的集合容器時能夠保證保存的數據的順序和想象中一致。 有人可能好奇上面的第二點若是違反了會怎樣呢?

舉個例子,若是你往一個 SortedSet 中前後添加兩個對象 a 和 b,a b 知足 (!a.equals(b) && a.compareTo(b) == 0),同時也沒有另外指定個 Comparator,那當你添加完 a 再添加 b 時會添加失敗返回 false, SortedSet 的 size 也不會增長,由於在 SortedSet 看來它們是相同的,而 SortedSet 中是不容許重複的。

實際上全部實現了 Comparable 接口的 Java 核心類的結果都和 equlas 方法保持一致。 實現了 Comparable 接口的 List 或則數組可使用 Collections.sort() 或者 Arrays.sort() 方法進行排序。

實現了 Comparable 接口的對象纔可以直接被用做 SortedMap (SortedSet) 的 key,要否則得在外邊指定 Comparator 排序規則。

所以本身定義的類若是想要使用有序的集合類,須要實現 Comparable 接口,好比:

**

  • description: 測試用的實體類 書, 實現了 Comparable 接口,天然排序

  • author: shixinzhang

  • data: 10/5/2016 */ public class BookBean implements Serializable, Comparable { private String name; private int count;

    public BookBean(String name, int count) { this.name = name; this.count = count; }

    public String getName() { return name; }

    public void setName(String name) { this.name = name; }

    public int getCount() { return count; }

    public void setCount(int count) { this.count = count; }

    /**

    • 重寫 equals

    • @param o

    • @return */ @Override public boolean equals(Object o) { if (this == o) return true; if (!(o instanceof BookBean)) return false;

      BookBean bean = (BookBean) o;

      if (getCount() != bean.getCount()) return false; return getName().equals(bean.getName());

    }

    /**

    • 重寫 hashCode 的計算方法
    • 根據全部屬性進行 迭代計算,避免重複
    • 計算 hashCode 時 計算因子 31 見得不少,是一個質數,不能再被除
    • @return */ @Override public int hashCode() { //調用 String 的 hashCode(), 惟一表示一個字符串內容 int result = getName().hashCode(); //乘以 31, 再加上 count result = 31 * result + getCount(); return result; }

    @Override public String toString() { return "BookBean{" + "name='" + name + ''' + ", count=" + count + '}'; }

    /**

    • 當向 TreeSet 中添加 BookBean 時,會調用這個方法進行排序

    • @param another

    • @return */ @Override public int compareTo(Object another) { if (another instanceof BookBean){ BookBean anotherBook = (BookBean) another; int result;

      //好比這裏按照書價排序
       result = getCount() - anotherBook.getCount();

      //或者按照 String 的比較順序 //result = getName().compareTo(anotherBook.getName());

      if (result == 0){   //當書價一致時,再對比書名。 保證全部屬性比較一遍
           result = getName().compareTo(anotherBook.getName());
       }
       return result;

      } // 同樣就返回 0 return 0; }

上述代碼還重寫了 equlas(), hashCode() 方法,自定義的類未來可能會進行比較時,建議重寫這些方法。

這裏我想表達的是在有些場景下 equals 和 compareTo 結果要保持一致,這時候不重寫 equals,使用 Object.equals 方法獲得的結果會有問題,好比說 HashMap.put() 方法,會先調用 key 的 equals 方法進行比較,而後才調用 compareTo。

後面重寫 compareTo 時,要判斷某個相同時對比下一個屬性,把全部屬性都比較一次。

Comparable

Comparable 接口屬於 Java 集合框架的一部分。

Comparator 定製排序

Comparator 在 java.util 包下,也是一個接口,JDK 1.8 之前只有兩個方法:

public interface Comparator<T> {

    public int compare(T lhs, T rhs);

    public boolean equals(Object object);
}

JDK 1.8 之後又新增了不少方法:

基本上都是跟 Function 相關的,這裏暫不介紹 1.8 新增的。

從上面內容可知使用天然排序須要類實現 Comparable,而且在內部重寫 comparaTo 方法。

而 Comparator 則是在外部制定排序規則,而後做爲排序策略參數傳遞給某些類,好比 Collections.sort(), Arrays.sort(), 或者一些內部有序的集合(好比 SortedSet,SortedMap 等)。

Comparator的使用方法 使用方式主要分三步:

建立一個 Comparator 接口的實現類,並賦值給一個對象 在 compare 方法中針對自定義類寫排序規則 將 Comparator 對象做爲參數傳遞給 排序類的某個方法 向排序類中添加 compare 方法中使用的自定義類 舉個例子:

// 1.建立一個實現 Comparator 接口的對象
Comparator comparator = new Comparator() {
    @Override
    public int compare(Object object1, Object object2) {
        if (object1 instanceof NewBookBean && object2 instanceof NewBookBean){
            NewBookBean newBookBean = (NewBookBean) object1;
            NewBookBean newBookBean1 = (NewBookBean) object2;
            //具體比較方法參照 天然排序的 compareTo 方法,這裏只舉個栗子
            return newBookBean.getCount() - newBookBean1.getCount();
        }
        return 0;
    }
};

//2.將此對象做爲形參傳遞給 TreeSet 的構造器中
TreeSet treeSet = new TreeSet(comparator);

//3.向 TreeSet 中添加 步驟 1 中 compare 方法中設計的類的對象
treeSet.add(new NewBookBean("A",34));
treeSet.add(new NewBookBean("S",1));
treeSet.add( new NewBookBean("V",46));
treeSet.add( new NewBookBean("Q",26));

其實能夠看到,Comparator 的使用是一種策略模式。 排序類中持有一個 Comparator 接口的引用:

Comparator<? super K> comparator;

而咱們能夠傳入各類自定義排序規則的 Comparator 實現類,對一樣的類制定不一樣的排序策略。

總結

Java 中的兩種排序方式:

Comparable 天然排序。(實體類實現)
Comparator 是定製排序。(沒法修改實體類時,直接在調用方建立)
同時存在時採用 Comparator(定製排序)的規則進行比較。

對於一些普通的數據類型(好比 String, Integer, Double…),它們默認實現了Comparable 接口,實現了 compareTo 方法,咱們能夠直接使用。

而對於一些自定義類,它們可能在不一樣狀況下須要實現不一樣的比較策略,咱們能夠新建立 Comparator 接口,而後使用特定的 Comparator 實現進行比較。

這就是 Comparable 和 Comparator 的區別。

微信公衆號【Java技術江湖】一位阿里 Java 工程師的技術小站。做者黃小斜,專一 Java 相關技術:SSM、SpringBoot、MySQL、分佈式、中間件、集羣、Linux、網絡、多線程,偶爾講點Docker、ELK,同時也分享技術乾貨和學習經驗,致力於Java全棧開發!(關注公衆號後回覆」資料「便可領取 3T 免費技術學習資源以及我我原創的程序員校招指南、Java學習指南等資源)

在這裏插入圖片描述

相關文章
相關標籤/搜索