Mengapa ConcurrentHashMap mencegah kunci dan nilai null?

JavaDoc dari ConcurrentHashMapmengatakan ini:

Suka Hashtabletapi tidak seperti HashMap, kelas ini tidak memungkinkan nulluntuk digunakan sebagai kunci atau nilai.

Pertanyaan saya: Kenapa?

Pertanyaan 2: Mengapa tidak Hashtablemengizinkan nol?

Saya telah menggunakan banyak HashMaps untuk menyimpan data. Tetapi ketika berganti ke ConcurrentHashMapsaya beberapa kali mengalami masalah karena NullPointerExceptions.

Dari penulis ConcurrentHashMapdirinya sendiri (Doug Lea) :

Alasan utama bahwa nulls tidak diizinkan di ConcurrentMaps (ConcurrentHashMaps, ConcurrentSkipListMaps) adalah bahwa ambiguitas yang mungkin hanya bisa ditoleransi di peta non-konkuren tidak dapat diakomodasi. Yang utama adalah bahwa jika map.get(key)kembali null, Anda tidak dapat mendeteksi apakah kunci secara eksplisit memetakan ke nullvs kunci tidak dipetakan. Dalam peta non-konkuren, Anda dapat memeriksanya melalui map.contains(key), tetapi pada peta konkuren, peta mungkin telah berubah di antara panggilan.

Saya percaya itu adalah, setidaknya sebagian, untuk memungkinkan Anda menggabungkan containsKeydan getmenjadi satu panggilan. Jika peta dapat menyimpan nol, tidak ada cara untuk mengetahui apakah getmengembalikan nol karena tidak ada kunci untuk nilai itu, atau hanya karena nilainya nol.

Mengapa itu menjadi masalah? Karena tidak ada cara aman untuk melakukannya sendiri. Ambil kode berikut:

if (m.containsKey(k)) {
   return m.get(k);
} else {
   throw new KeyNotPresentException();
}

Karena mini adalah peta konkuren, kunci k dapat dihapus di antaracontainsKey dan getpanggilan, menyebabkan potongan ini mengembalikan nol yang tidak pernah ada dalam tabel, daripada yang diinginkan KeyNotPresentException.

Biasanya Anda akan menyelesaikannya dengan menyinkronkan, tetapi dengan peta bersamaan yang tentu saja tidak akan berfungsi. Karenanya tanda tangan untuk getharus berubah, dan satu-satunya cara untuk melakukan itu dengan cara yang kompatibel-mundur adalah mencegah pengguna memasukkan nilai nol di tempat pertama, dan terus menggunakannya sebagai pengganti untuk "kunci tidak ditemukan".

Josh Bloch dirancang HashMap; Doug Lea dirancang ConcurrentHashMap. Saya harap itu tidak memfitnah. Sebenarnya saya pikir masalahnya adalah bahwa nulls sering membutuhkan pembungkus sehingga null yang sebenarnya dapat berdiri untuk diinisialisasi. Jika kode klien membutuhkan nol maka dapat membayar biaya pembatalan nol itu sendiri.

Anda tidak dapat menyinkronkan pada nol.

Sunting: Ini tidak persis mengapa dalam hal ini. Saya awalnya berpikir ada sesuatu yang mewah terjadi dengan mengunci hal-hal terhadap pembaruan bersamaan atau menggunakan monitor Obyek untuk mendeteksi jika ada sesuatu yang dimodifikasi, tetapi setelah memeriksa kode sumber tampaknya saya salah - mereka mengunci menggunakan "segmen" berdasarkan pada bitmask hash.

Dalam hal itu, saya curiga mereka melakukannya untuk menyalin Hashtable, dan saya curiga Hashtable melakukannya karena di dunia basis data relasional, null! = Null, jadi menggunakan null sebagai kunci tidak ada artinya.

ConcurrentHashMap aman digunakan. Saya percaya bahwa tidak mengizinkan kunci dan nilai null adalah bagian dari memastikan bahwa itu adalah thread-safe.

Saya kira cuplikan dari dokumentasi API berikut ini memberikan petunjuk yang baik: "Kelas ini sepenuhnya dapat dioperasikan dengan Hashtable dalam program yang mengandalkan keamanan utangnya tetapi tidak pada detail sinkronisasi."

Mereka mungkin hanya ingin membuat ConcurrentHashMapsepenuhnya kompatibel / dipertukarkan ke Hashtable. Dan karena Hashtabletidak memungkinkan kunci dan nilai null ..

Saya tidak berpikir menolak nilai nol adalah pilihan yang benar. Dalam banyak kasus, kami ingin memasukkan kunci dengan nilai nol ke dalam peta saat ini. Namun, dengan menggunakan ConcurrentHashMap, kami tidak dapat melakukannya. Saya menyarankan agar versi JDK yang akan datang dapat mendukungnya.