有關如何線程安全的使用map(hashMap)


最近在寫一個多線程中控制輸出順序的系統中的一個代碼,使用了map的數據結構。具體的業務是需要一個單例的對象,然后需要在多線程的環境下實現添加和刪除的操作。部分代碼如下:

public class UploadImageNumCache {

    /**
     * 
    
    private Map<Integer, Map<Integer, Integer>> UploadImageNumMap = Collections
            .synchronizedMap(new HashMap<Integer, Map<Integer, Integer>>());
     */
    private Map<Integer, Map<Integer, Integer>> UploadImageNumMap = new ConcurrentHashMap<Integer, Map<Integer,Integer>>();

    /**
     * 
     */
    private static UploadImageNumCache uploadImageNumCache = null;

    /**
     * 私有構造
     */
    private UploadImageNumCache() {

    }

    /**
     * 添加
     * 
     * @param documentId
     *            文檔id
     * @param pageNow
     *            頁碼
     */
    public synchronized void addUploadImageNumMap(Integer documentId, Integer pageNow) {

        if (UploadImageNumMap.containsKey(documentId)) {
            UploadImageNumMap.get(documentId).put(pageNow, Constants.IMAGE_UPLOAD_STATUS_NO);
        } else {
            Map<Integer, Integer> map = new HashMap<Integer, Integer>();
            map.put(pageNow, Constants.IMAGE_UPLOAD_STATUS_NO);
            UploadImageNumMap.put(documentId, map);
        }
    }
/**
     * 刪除
     * 
     * @param documentId
     */
    public synchronized void deleteUploadImageNumMap(Integer documentId) {
        if (UploadImageNumMap.containsKey(documentId)) {
            UploadImageNumMap.remove(documentId);
        }
    }
/**
     * 清除緩存
     */
    public synchronized void clearUploadImageNumMap() {
        if (!UploadImageNumMap.isEmpty()) {
            UploadImageNumMap.clear();
        }
    }

    /**
     * 獲取單例
     * 
     * @return
     */
    public static UploadImageNumCache getInstance() {
        if (uploadImageNumCache == null) {
            synchronized (UploadImageNumCache.class) {
                if (uploadImageNumCache == null) {
                    uploadImageNumCache = new UploadImageNumCache();
                }
            }
        }
        return uploadImageNumCache;
    }

從上面的代碼中可以看到使用了map的數據結構來存放。但是在這里是修改過的代碼。之前直接使用了hashmap。但是遇到一個很嚴重的問題就是多線程環境下的線程安全問題。我們都知道map,hashmap不是線程安全的。記得之前的面試的時候問過list如何實現線程安全,當時沒有答上來,出來后就百度了以下,知道是使用的Collections .synchronizedList。但是寫map的時候竟然沒有想起來。
實在是慚愧阿。今天就對這些涉及到的集合中的線程安全問題進行一個總結,多總結多進步阿。

首先說以下 java中集合的兩種分類。底層來說的話分兩類collection和map:

Collection
├List
│├LinkedList
│├ArrayList
│└Vector
│ └Stack
└Set
Map
├Hashtable
├HashMap
└WeakHashMap。這個圖比較詳細的說明了。

我們說集合中有些是線程安全的有例如:Vector,HashTable等。這些類之所以是線程安全的是因為,這些類是在jdk1.5之前,甚至是1.2版本的,我們看這些類的源碼就可以知道里面都有sychronized這個線程安全關鍵字。但是之后出的ArrayList,HashMap等,一般都是線程不安全的。也不知道是基於什么考慮的,這個有時間可以研究以下。今天主要對hashmap和list的線程安全實現做一個介紹,至於hashtable這個線程安全和hashmap的區別不是今天要說的內容。

好了既然我們知道map,hashmap不是線程安全的,但是如何證明呢,下面的這個程序大家可以自己試一下,看看能不能將到5000 正確的輸出來。:

 

/**
 * 
 * @author duanxj
 *
 * @version 
 *
 * @date May 8, 2017
 */
public class ThreadNotSafeHashmap {
    public static void main(String args[]) throws InterruptedException {
        final HashMap<String, String> firstHashMap = new HashMap<String, String>();
        Thread t1 = new Thread() {
            public void run() {
                for (int i = 0; i < 2500; i++) {
                    firstHashMap.put(String.valueOf(i), String.valueOf(i));
                }
            }
        };
        Thread t2 = new Thread() {
            public void run() {
                for (int j = 2500; j < 5000; j++) {
                    firstHashMap.put(String.valueOf(j), String.valueOf(j));
                }
            }
        };
        t1.start();
       t2.start();

        Thread.sleep(1000);
        for (int k = 0; k < 5000; k++) {
            if (String.valueOf(k).equals(firstHashMap.get(String.valueOf(k)))) {
                System.err.println(String.valueOf(k) + ":" + firstHashMap.get(String.valueOf(k)));
            }
        }
    }
}

 

而且你要多試幾次,你會發現每次跟每次少的元素都不一樣。這下明白為什么不是線程安全的了吧。下面說到這里未還想說以下,有些人說多線程對hashmap進行添加和刪除的時候會拋出異常。這種說法是不准確的,雖然我們知道在對list進行遍歷的時候不能對list做刪除操作,會拋出異常,但是在map中並不會拋出同樣的異常。至於為什么大家百度以下。

上面是一個證明map線程不安全的例子,既然是線程不安全的,那總得知道為什么把:

總說HashMap是線程不安全的,不安全的,不安全的,那么到底為什么它是線程不安全的呢?要回答這個問題就要先來簡單了解一下HashMap源碼中的使用的存儲結構(這里引用的是Java 8的源碼,與7是不一樣的)和它的擴容機制

HashMap的內部存儲結構

下面是HashMap使用的存儲結構:

1
2
3
4
5
6
7
8
transient Node<K,V>[] table;
 
static class Node<K,V> implements Map.Entry<K,V> {
         final int hash;
         final K key;
         V value;
         Node<K,V> next;
}

可以看到HashMap內部存儲使用了一個Node數組(默認大小是16),而Node類包含一個類型為Node的next的變量,也就是相當於一個鏈表,所有hash值相同(即產生了沖突)的key會存儲到同一個鏈表里,這是他底層的存儲結構,那從這個結構中我們分析為什么是線程不安全的呢?

       個人覺得HashMap在並發時可能出現的問題主要是兩方面,首先如果多個線程同時使用put方法添加元素,而且假設正好存在兩個put的key發 生了碰撞(hash值一樣),那么根據HashMap的實現,這兩個key會添加到數組的同一個位置,這樣最終就會發生其中一個線程的put的數據被覆 蓋。第二就是如果多個線程同時檢測到元素個數超過數組大小*loadFactor,這樣就會發生多個線程同時對Node數組進行擴容,都在重新計算元素位 置以及復制數據,但是最終只有一個線程擴容后的數組會賦給table,也就是說其他線程的都會丟失,並且各自線程put的數據也丟失。
關於HashMap線程不安全這一點,《Java並發編程的藝術》一書中是這樣說的:

HashMap在並發執行put操作時會引起死循環,導致CPU利用率接近100%。因為多線程會導致HashMap的Node鏈表形成環形數據結構,一旦形成環形數據結構,Node的next節點永遠不為空,就會在獲取Node時產生死循環。

哇塞,聽上去si不si好神奇,居然會產生死循環。。。。google了一下,才知道死循環並不是發生在put操作時,而是發生在擴容時。詳細的解釋可以看下面幾篇博客:

既然知道了為什么,那就要去解決,如何解決呢,到目前為止有下面三種解決方法:

  • Hashtable   ConcurrentHashMap   Synchronized Map
  • 下面按照這個順序對每一個進行說明。順便說一下他們的效率問題:
  • 例子:

  •  

    //Hashtable
    Map<String, String> hashtable = new Hashtable<>();
     
    //synchronizedMap
    Map<String, String> synchronizedHashMap = Collections.synchronizedMap(new HashMap<String, String>());
     
    //ConcurrentHashMap
    Map<String, String> concurrentHashMap = new ConcurrentHashMap<>();

     

     

    依次來看看。

    Hashtable

    先稍微吐槽一下,為啥命名不是HashTable啊,看着好難受,不管了就裝作它叫HashTable吧。這貨已經不常用了,就簡單說說吧。HashTable源碼中是使用synchronized來保證線程安全的,比如下面的get方法和put方法:

    1
    2
    3
    4
    5
    6
    public synchronized V get(Object key) {
           // 省略實現
        }
    public synchronized V put(K key, V value) {
        // 省略實現
        }

     

    所以當一個線程訪問HashTable的同步方法時,其他線程如果也要訪問同步方法,會被阻塞住。舉個例子,當一個線程使用put方法時,另一個線程不但不可以使用put方法,連get方法都不可以,好霸道啊!!!so~~,效率很低,現在基本不會選擇它了。

    ConcurrentHashMap

    ConcurrentHashMap(以下簡稱CHM)是JUC包中的一個類,Spring的源碼中有很多使用CHM的地方。之前已經翻譯過一篇關於ConcurrentHashMap的博客,如何在java中使用ConcurrentHashMap, 里面介紹了CHM在Java中的實現,CHM的一些重要特性和什么情況下應該使用CHM。需要注意的是,上面博客是基於Java 7的,和8有區別,在8中CHM摒棄了Segment(鎖段)的概念,而是啟用了一種全新的方式實現,利用CAS算法,有時間會重新總結一下。

    SynchronizedMap

    看了一下源碼,SynchronizedMap的實現還是很簡單的。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    // synchronizedMap方法
    public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) {
           return new SynchronizedMap<>(m);
       }
    // SynchronizedMap類
    private static class SynchronizedMap<K,V>
           implements Map<K,V>, Serializable {
           private static final long serialVersionUID = 1978198479659022715L;
     
           private final Map<K,V> m;     // Backing Map
           final Object      mutex;        // Object on which to synchronize
     
           SynchronizedMap(Map<K,V> m) {
               this.m = Objects.requireNonNull(m);
               mutex = this;
           }
     
           SynchronizedMap(Map<K,V> m, Object mutex) {
               this.m = m;
               this.mutex = mutex;
           }
     
           public int size() {
               synchronized (mutex) {return m.size();}
           }
           public boolean isEmpty() {
               synchronized (mutex) {return m.isEmpty();}
           }
           public boolean containsKey(Object key) {
               synchronized (mutex) {return m.containsKey(key);}
           }
           public boolean containsValue(Object value) {
               synchronized (mutex) {return m.containsValue(value);}
           }
           public V get(Object key) {
               synchronized (mutex) {return m.get(key);}
           }
     
           public V put(K key, V value) {
               synchronized (mutex) {return m.put(key, value);}
           }
           public V remove(Object key) {
               synchronized (mutex) {return m.remove(key);}
           }
           // 省略其他方法
       }

     

    從源碼中可以看出調用synchronizedMap()方法后會返回一個SynchronizedMap類的對象,而在SynchronizedMap類中使用了synchronized同步關鍵字來保證對Map的操作是線程安全的。

    性能對比

    這是要靠數據說話的時代,所以不能只靠嘴說CHM快,它就快了。寫個測試用例,實際的比較一下這三種方式的效率(源碼來源),下面的代碼分別通過三種方式創建Map對象,使用ExecutorService來並發運行5個線程,每個線程添加/獲取500K個元素。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    public class CrunchifyConcurrentHashMapVsSynchronizedMap {
     
        public final static int THREAD_POOL_SIZE = 5;
     
        public static Map<String, Integer> crunchifyHashTableObject = null;
        public static Map<String, Integer> crunchifySynchronizedMapObject = null;
        public static Map<String, Integer> crunchifyConcurrentHashMapObject = null;
     
        public static void main(String[] args) throws InterruptedException {
     
            // Test with Hashtable Object
            crunchifyHashTableObject = new Hashtable<>();
            crunchifyPerformTest(crunchifyHashTableObject);
     
            // Test with synchronizedMap Object
            crunchifySynchronizedMapObject = Collections.synchronizedMap(new HashMap<String, Integer>());
            crunchifyPerformTest(crunchifySynchronizedMapObject);
     
            // Test with ConcurrentHashMap Object
            crunchifyConcurrentHashMapObject = new ConcurrentHashMap<>();
            crunchifyPerformTest(crunchifyConcurrentHashMapObject);
     
        }
     
        public static void crunchifyPerformTest(final Map<String, Integer> crunchifyThreads) throws InterruptedException {
     
            System.out.println("Test started for: " + crunchifyThreads.getClass());
            long averageTime = 0;
            for (int i = 0; i < 5; i++) {
     
                long startTime = System.nanoTime();
                ExecutorService crunchifyExServer = Executors.newFixedThreadPool(THREAD_POOL_SIZE);
     
                for (int j = 0; j < THREAD_POOL_SIZE; j++) {
                    crunchifyExServer.execute(new Runnable() {
                        @SuppressWarnings("unused")
                        @Override
                        public void run() {
     
                            for (int i = 0; i < 500000; i++) {
                                Integer crunchifyRandomNumber = (int) Math.ceil(Math.random() * 550000);
     
                                // Retrieve value. We are not using it anywhere
                                Integer crunchifyValue = crunchifyThreads.get(String.valueOf(crunchifyRandomNumber));
     
                                // Put value
                                crunchifyThreads.put(String.valueOf(crunchifyRandomNumber), crunchifyRandomNumber);
                            }
                        }
                    });
                }
     
                // Make sure executor stops
                crunchifyExServer.shutdown();
     
                // Blocks until all tasks have completed execution after a shutdown request
                crunchifyExServer.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);
     
                long entTime = System.nanoTime();
                long totalTime = (entTime - startTime) / 1000000L;
                averageTime += totalTime;
                System.out.println("2500K entried added/retrieved in " + totalTime + " ms");
            }
            System.out.println("For " + crunchifyThreads.getClass() + " the average time is " + averageTime / 5 + " ms\n");
        }
    }

     

    測試結果:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    Test started for: class java.util.Hashtable
    2500K entried added/retrieved in 2018 ms
    2500K entried added/retrieved in 1746 ms
    2500K entried added/retrieved in 1806 ms
    2500K entried added/retrieved in 1801 ms
    2500K entried added/retrieved in 1804 ms
    For class java.util.Hashtable the average time is 1835 ms
     
    Test started for: class java.util.Collections$SynchronizedMap
    2500K entried added/retrieved in 3041 ms
    2500K entried added/retrieved in 1690 ms
    2500K entried added/retrieved in 1740 ms
    2500K entried added/retrieved in 1649 ms
    2500K entried added/retrieved in 1696 ms
    For class java.util.Collections$SynchronizedMap the average time is 1963 ms
     
    Test started for: class java.util.concurrent.ConcurrentHashMap
    2500K entried added/retrieved in 738 ms
    2500K entried added/retrieved in 696 ms
    2500K entried added/retrieved in 548 ms
    2500K entried added/retrieved in 1447 ms
    2500K entried added/retrieved in 531 ms
    For class java.util.concurrent.ConcurrentHashMap the average time is 792 ms

     

    這個就不用廢話了,CHM性能是明顯優於Hashtable和SynchronizedMap的,CHM花費的時間比前兩個的一半還少.
  • 哈哈哈  上面的分析是參考的這個兄弟的。www.importnew.com/21396.html 覺着寫的很好,權當未參考參考。通過上面的分析我們看到其實建議使用

    ConcurrentHashMap來實現map的線程安全問題。

  • 對於list如何顯示線程安全,其實使用的也是collections包中的Collections.synchronizedList(new ArrayList<Map<String,Object>>());

 

例子:

1
2
3
4
5
6
7
8
//Hashtable
Map<String, String> hashtable = new Hashtable<>();
 
//synchronizedMap
Map<String, String> synchronizedHashMap = Collections.synchronizedMap( new HashMap<String, String>());
 
//ConcurrentHashMap
Map<String, String> concurrentHashMap = new ConcurrentHashMap<>();

依次來看看。

Hashtable

先稍微吐槽一下,為啥命名不是HashTable啊,看着好難受,不管了就裝作它叫HashTable吧。這貨已經不常用了,就簡單說說吧。HashTable源碼中是使用synchronized來保證線程安全的,比如下面的get方法和put方法:

1
2
3
4
5
6
public synchronized V get(Object key) {
        // 省略實現
     }
public synchronized V put(K key, V value) {
     // 省略實現
     }

所以當一個線程訪問HashTable的同步方法時,其他線程如果也要訪問同步方法,會被阻塞住。舉個例子,當一個線程使用put方法時,另一個線程不但不可以使用put方法,連get方法都不可以,好霸道啊!!!so~~,效率很低,現在基本不會選擇它了。

ConcurrentHashMap

ConcurrentHashMap(以下簡稱CHM)是JUC包中的一個類,Spring的源碼中有很多使用CHM的地方。之前已經翻譯過一篇關於ConcurrentHashMap的博客,如何在java中使用ConcurrentHashMap, 里面介紹了CHM在Java中的實現,CHM的一些重要特性和什么情況下應該使用CHM。需要注意的是,上面博客是基於Java 7的,和8有區別,在8中CHM摒棄了Segment(鎖段)的概念,而是啟用了一種全新的方式實現,利用CAS算法,有時間會重新總結一下。

SynchronizedMap

看了一下源碼,SynchronizedMap的實現還是很簡單的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// synchronizedMap方法
public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) {
        return new SynchronizedMap<>(m);
    }
// SynchronizedMap類
private static class SynchronizedMap<K,V>
        implements Map<K,V>, Serializable {
        private static final long serialVersionUID = 1978198479659022715L;
 
        private final Map<K,V> m;     // Backing Map
        final Object      mutex;        // Object on which to synchronize
 
        SynchronizedMap(Map<K,V> m) {
            this .m = Objects.requireNonNull(m);
            mutex = this ;
        }
 
        SynchronizedMap(Map<K,V> m, Object mutex) {
            this .m = m;
            this .mutex = mutex;
        }
 
        public int size() {
            synchronized (mutex) { return m.size();}
        }
        public boolean isEmpty() {
            synchronized (mutex) { return m.isEmpty();}
        }
        public boolean containsKey(Object key) {
            synchronized (mutex) { return m.containsKey(key);}
        }
        public boolean containsValue(Object value) {
            synchronized (mutex) { return m.containsValue(value);}
        }
        public V get(Object key) {
            synchronized (mutex) { return m.get(key);}
        }
 
        public V put(K key, V value) {
            synchronized (mutex) { return m.put(key, value);}
        }
        public V remove(Object key) {
            synchronized (mutex) { return m.remove(key);}
        }
        // 省略其他方法
    }

從源碼中可以看出調用synchronizedMap()方法后會返回一個SynchronizedMap類的對象,而在SynchronizedMap類中使用了synchronized同步關鍵字來保證對Map的操作是線程安全的。

性能對比

這是要靠數據說話的時代,所以不能只靠嘴說CHM快,它就快了。寫個測試用例,實際的比較一下這三種方式的效率(源碼來源),下面的代碼分別通過三種方式創建Map對象,使用ExecutorService來並發運行5個線程,每個線程添加/獲取500K個元素。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
public class CrunchifyConcurrentHashMapVsSynchronizedMap {
 
     public final static int THREAD_POOL_SIZE = 5 ;
 
     public static Map<String, Integer> crunchifyHashTableObject = null ;
     public static Map<String, Integer> crunchifySynchronizedMapObject = null ;
     public static Map<String, Integer> crunchifyConcurrentHashMapObject = null ;
 
     public static void main(String[] args) throws InterruptedException {
 
         // Test with Hashtable Object
         crunchifyHashTableObject = new Hashtable<>();
         crunchifyPerformTest(crunchifyHashTableObject);
 
         // Test with synchronizedMap Object
         crunchifySynchronizedMapObject = Collections.synchronizedMap( new HashMap<String, Integer>());
         crunchifyPerformTest(crunchifySynchronizedMapObject);
 
         // Test with ConcurrentHashMap Object
         crunchifyConcurrentHashMapObject = new ConcurrentHashMap<>();
         crunchifyPerformTest(crunchifyConcurrentHashMapObject);
 
     }
 
     public static void crunchifyPerformTest( final Map<String, Integer> crunchifyThreads) throws InterruptedException {
 
         System.out.println( "Test started for: " + crunchifyThreads.getClass());
         long averageTime = 0 ;
         for ( int i = 0 ; i < 5 ; i++) {
 
             long startTime = System.nanoTime();
             ExecutorService crunchifyExServer = Executors.newFixedThreadPool(THREAD_POOL_SIZE);
 
             for ( int j = 0 ; j < THREAD_POOL_SIZE; j++) {
                 crunchifyExServer.execute( new Runnable() {
                     @SuppressWarnings ( "unused" )
                     @Override
                     public void run() {
 
                         for ( int i = 0 ; i < 500000 ; i++) {
                             Integer crunchifyRandomNumber = ( int ) Math.ceil(Math.random() * 550000 );
 
                             // Retrieve value. We are not using it anywhere
                             Integer crunchifyValue = crunchifyThreads.get(String.valueOf(crunchifyRandomNumber));
 
                             // Put value
                             crunchifyThreads.put(String.valueOf(crunchifyRandomNumber), crunchifyRandomNumber);
                         }
                     }
                 });
             }
 
             // Make sure executor stops
             crunchifyExServer.shutdown();
 
             // Blocks until all tasks have completed execution after a shutdown request
             crunchifyExServer.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);
 
             long entTime = System.nanoTime();
             long totalTime = (entTime - startTime) / 1000000L;
             averageTime += totalTime;
             System.out.println( "2500K entried added/retrieved in " + totalTime + " ms" );
         }
         System.out.println( "For " + crunchifyThreads.getClass() + " the average time is " + averageTime / 5 + " ms\n" );
     }
}

測試結果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Test started for : class java.util.Hashtable
2500K entried added/retrieved in 2018 ms
2500K entried added/retrieved in 1746 ms
2500K entried added/retrieved in 1806 ms
2500K entried added/retrieved in 1801 ms
2500K entried added/retrieved in 1804 ms
For class java.util.Hashtable the average time is 1835 ms
 
Test started for : class java.util.Collections$SynchronizedMap
2500K entried added/retrieved in 3041 ms
2500K entried added/retrieved in 1690 ms
2500K entried added/retrieved in 1740 ms
2500K entried added/retrieved in 1649 ms
2500K entried added/retrieved in 1696 ms
For class java.util.Collections$SynchronizedMap the average time is 1963 ms
 
Test started for : class java.util.concurrent.ConcurrentHashMap
2500K entried added/retrieved in 738 ms
2500K entried added/retrieved in 696 ms
2500K entried added/retrieved in 548 ms
2500K entried added/retrieved in 1447 ms
2500K entried added/retrieved in 531 ms
For class java.util.concurrent.ConcurrentHashMap the average time is 792 ms

這個就不用廢話了,CHM性能是明顯優於Hashtable和SynchronizedMap的,CHM花費的時間比前兩個的一半還少


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM