一致性hashjava

⑴ java hashcode相同，equals一定為真equals為真，hashcode不一定為真

hashcode()和equals(object
o)方法是java所有類的基類object類中的方法，所有類都繼承了object類以及其中的方法。equals與hashcode的定義必須一致，即：如果x.equals(y)返回true，那麼x.hashcode()就必須與y.hashcode()具有相同的值。當然，對於兩個不同的對象，x.hashcode()與y.hashcode()基本不會相同（不排除極少數情況會相同）。
在基類object類中，默認的equals方法是判斷兩個對象是否具有相同的引用，如果具有相同的引用，那它們必然是相等的。不過這種判斷方法並不是一直都通用，比如：有的時候，兩輛汽車，只要型號配置相同，就可以認為是相等的，出廠日期可以忽略不計。這種時候就需要在你的類中重寫equals方法，對於這個類用你自己的方法來判斷兩個對象是否相等（重寫equals方法就必須重新定義hashcode()方法）。
註：如果對兩個對象進行==操作，那麼就會自動調用object類默認的equals方法來進行比較。希望能幫到你~

⑵ 如何正確實現Java中的hashCode方法

正確實現Java中的hashCode方法：
相等和哈希碼

相等是從一般的方面來講，哈希碼更加具有技術性。如果我們在理解方面存在困難,我們可以說,他們通過只是一個實現細節來提高了性能。
大多數的數據結構通過equals方法來判斷他們是否包含一個元素，例如：
List<String> list = Arrays.asList("a", "b", "c");
boolean contains = list.contains("b");

這個變數contains結果是true，因為,雖然」b」是不相同的實例(此外,忽略字元串駐留),但是他們是相等的。
通過比較實例的每個元素，然後將比較結果賦值給contains是比較浪費的，雖然整個類的數據結構進行了優化，能夠提升性能。
他們通過使用一種快捷的方式(減少潛在的實例相等)進行比較，從而代替通過比較實例所包含的每個元素。而快捷比較僅需要比較下面這些方面：
快捷方式比較即通過比較哈希值，它可以將一個實例用一個整數值來代替。哈希碼相同的實例不一定相等，但相等的實例一定具有有相同的哈希值。(或應該有,我們很快就會討論這個)這些數據結構經常通過這種這種技術來命名,可以通過Hash來識別他們的,其中，HashMap是其中最著名的代表。
它們通常是這樣這樣運作的
當添加一個元素,它的哈希碼是用來計算內部數組的索引(即所謂的桶)
如果是,不相等的元素有相同的哈希碼,他們最終在同一個桶上並且捆綁在一起,例如通過添加到列表。
當一個實例來進行contains操作時，它的哈希碼將用來計算桶值(索引值)，只有當對應索引值上存在元素時，才會對實例進行比較。
因此equals，hashCode是定義在Object類中。
散列法的思想
如果hashCode作為快捷方式來確定相等，那麼只有一件事我們應該關心:相等的對象應該具有相同的哈希碼，這也是為什麼如果我們重寫了equals方法後，我們必須創建一個與之匹配的hashCode實現的原因!
否則相等的對象是可能不會有相同的哈希碼的,因為它們將調用的是Object's的默認實現。
HashCode 准則
引用自官方文檔
hashCode通用約定:
* 調用運行Java應用程序中的同一對象,hashCode方法必須始終返回相同的整數。這個整數不需要在不同的Java應用程序中保持一致。
* 根據equals(Object)的方法來比較，如果兩個對象是相等的,兩個對象調用hashCode方法必須產生相同的結果。
* 根據equals(Object)的方法是比較，如果兩個對象是不相等的，那麼兩個對象調用hashCode方法並不一定產生不同的整數的結果。但是,程序員應該意識到給不相等的對象產生不同的整數結果將有可能提高哈希表的性能。
第一點反映出了相等的一致性屬性，第二個就是我們上面提出的要求。第三個闡述了一個重要的細節，我們將在稍後討論。
HashCode實現
下面是非常簡單的Person.hashCode的實現
@Override
public int hashCode() {
return Objects.hash(firstName, lastName);
}

person』s是通過多個欄位結合來計算哈希碼的。都是通過Object的hash函數來計算。
選擇欄位
但哪些欄位是相關的嗎?需求將會幫助我們回答這個問題:如果相等的對象必須具有相同的哈希碼,那麼計算哈希碼就不應包括任何不用於相等檢查的欄位。(否則兩個對象只是這些欄位不同但是仍然有可能會相等，此時他們這兩個對象哈希碼卻會不相同。)
所以用於哈希組欄位應該相等時使用的欄位的子集。默認情況下都使用相同的欄位,但有一些細節需要考慮。
一致性
首先,有一致性的要求。它應該相當嚴格。雖然它允許如果一些欄位改變對應的哈希碼發生變化(對於可變的類是不可避免的)，但是哈希數據結構並不是為這種場景准備的。
正如我們以上所見的哈希碼用於確定元素的桶。但如果hash-relevant欄位發生了改變,並不會重新計算哈希碼、也不會更新內部數組。
這意味著以後通過相等的對象，甚至同一實例進行查詢也會失敗，數據結構計算當前的哈希碼與之前存儲實例計算的哈希碼並不一致,並是錯誤的桶。
結論:最好不要使用可變欄位計算哈希碼!
性能
哈希碼最終計算的頻率與可能調用equals差不多，那麼這里將是影響性能的關鍵部分，因此考慮此部分性能也是非常有意義的。並且與equals相比，優化之後又更大的上升空間。
除非使用非常復雜的演算法或者涉及非常多的欄位，那麼計算哈希碼的運算成本是微不足道的、同樣也是不可避免的。但是也應該考慮是否需要包含所有的欄位來進行運算。集合需要特別警惕的對待。以Lists和sets為例，將會包含集合裡面的每一個元素來計算哈希碼。是否需要調用它們需要具體情況具體分析。
如果性能是至關重要的，使用Objects.hash因為需要為varargs創建一個數組也許並不是最好的選擇。但一般規則優化是適用的:不要過早地使用一個通用的散列碼演算法,也許需要放棄集合,只有優化分析顯示潛在的改進。
碰撞
總是關注性能,這個實現怎麼呢?
@Override
public int hashCode() {
return 0;
}

快是肯定的。相等的對象將具有相同的哈希碼。並且,沒有可變的欄位!
但是，我們之前說過的桶呢？！這種方式下所有的實例將會有相同的桶！這將會導致一個鏈表來包含所有的元素，這樣一來將會有非常差的性能。每次調用contains將會觸發對整個list線性掃描。
我們希望盡可能少的元素在同一個桶!一個演算法返回變化多端的哈希碼,即使對於非常相似的對象,是一個好的開始。
怎樣才能達到上面的效果部分取決於選取的欄位，我們在計算中包含更多的細節，越有可能獲取到不同的哈希碼。注意：這個與我們所說的性能是完全相反的。因此，有趣的是，使用過多或者過少的欄位都會導致糟糕的性能。
防止碰撞的另一部分是使用實際計算散列的演算法。
計算Hsah
最簡單的方法來計算一個欄位的哈希碼是通過直接調用hashCode，結合的話會自動完成。常見的演算法是首先在以任意數量的數值(通常是基本數據類型)反復進行相乘操作再與欄位哈希碼相加
int prime = 31;
int result = 1;
result = prime * result + ((firstName == null) ? 0 : firstName.hashCode());
result = prime * result + ((lastName == null) ? 0 : lastName.hashCode());
return result;

這可能導致溢出,但是不是特別有問題的,因為他們並沒有產生Java異常。
注意,即使是非常良好的的哈希演算法也可能因為輸入特定的模式的數據有導致頻繁碰撞。作為一個簡單的例子假設我們會計算點的散列通過增加他們的x和y坐標。當我們處理f(x) = -x線上的點時，線上的點都滿足：x + y == 0，將會有大量的碰撞。
但是:我們可以使用一個通用的演算法，只到分析表明並不正確，才需要對哈希演算法進行修改。
總結
我們了解到計算哈希碼就是壓縮相等的一個整數值：相等的對象必須有相同的哈希碼，而出於對性能的考慮：最好是盡可能少的不相等的對象共享相同的哈希碼。
這就意味著如果重寫了equals方法，那麼就必須重寫hashCode方法
當實現hashCode
使用與equals中使用的相同的欄位(或者equals中使用欄位的子集)
最好不要包含可變的欄位。
對集合不要考慮調用hashCode
如果沒有特殊的輸入特定的模式，盡量採用通用的哈希演算法
記住hashCode性能,所以除非分析表明必要性，否則不要浪費太多的精力。

⑶ java中的equals，hashcode的區別和聯系

equals
publicbooleanequals(Objectobj)
指示其他某個對象是否與此對象「相等」。
equals方法在非空對象引用上實現相等關系：
自反性：對於任何非空引用值x，x.equals(x)都應返回
true。
對稱性：對於任何非空引用值x和y，當且僅當
y.equals(x)返回true時，x.equals(y)才應返回
true。
傳遞性：對於任何非空引用值x、y和z，如果
x.equals(y)返回true，並且y.equals(z)返回
true，那麼x.equals(z)應返回true。
一致性：對於任何非空引用值x和y，多次調用
x.equals(y)始終返回true或始終返回false，前提是對象上
equals比較中所用的信息沒有被修改。
對於任何非空引用值x，x.equals(null)都應返回
false。
Object類的equals方法實現對象上差別可能性最大的相等關系；即，對於任何非空引用值
x和y，當且僅當x和y引用同一個對象時，此方法才返回true（x==y具有值true）。
注意：當此方法被重寫時，通常有必要重寫hashCode方法，以維護hashCode方法的常規協定，該協定聲明相等對象必須具有相等的哈希碼。

參數：
obj-要與之比較的引用對象。
返回：
如果此對象與obj參數相同，則返回true；否則返回false。
另請參見：
hashCode(),Hashtable

hashCode
publicinthashCode()
返回該對象的哈希碼值。支持此方法是為了提高哈希表（例如java.util.Hashtable提供的哈希表）的性能。
hashCode的常規協定是：
在Java應用程序執行期間，在對同一對象多次調用hashCode方法時，必須一致地返回相同的整數，前提是將對象進行
equals比較時所用的信息沒有被修改。從某一應用程序的一次執行到同一應用程序的另一次執行，該整數無需保持一致。
如果根據equals(Object)方法，兩個對象是相等的，那麼對這兩個對象中的每個對象調用
hashCode方法都必須生成相同的整數結果。
如果根據equals(java.lang.Object)方法，兩個對象不相等，那麼對這兩個對象中的任一對象上調用hashCode方法不要求一定生成不同的整數結果。但是，程序員應該意識到，為不相等的對象生成不同整數結果可以提高哈希表的性能。
實際上，由Object類定義的hashCode
方法確實會針對不同的對象返回不同的整數。（這一般是通過將該對象的內部地址轉換成一個整數來實現的，但是JavaTM編程語言不需要這種實現技巧。）

返回：
此對象的一個哈希碼值。
另請參見：
equals(java.lang.Object),
Hashtable

也就是說equals和hashCode的關系只是在於一個協定，equals默認判斷依據是對象是否相等，hashCode()得到對象的內存地址的一個特殊計算得到的值，協定內容是：equals相等的對象的hashCode值相等，所以要求重寫了equals之後重寫hashCode。

equals是判斷對象是否相等的方法。hashCode是得到對象hash值的方法，對象hash值默認是根據內存地址計算得到。equals默認表的是對象內存地址。

⑷ java中Hashtable和HashMap的區別分析

1 HashMap不是線程安全的

hastmap是一個介面 是map介面的子介面，是將鍵映射到值的對象，其中鍵和值都是對象，並且不能包含重復鍵，但可以包含重復值。HashMap允許null key和null value，而hashtable不允許。

2 HashTable是線程安全的一個Collection。

HashMap是Hashtable的輕量級實現（非線程安全的實現），他們都完成了Map介面，主要區別在於HashMap允許空（null）鍵值（key）,由於非線程安全，效率上可能高於Hashtable。
HashMap允許將null作為一個entry的key或者value，而Hashtable不允許。
HashMap把Hashtable的contains方法去掉了，改成containsvalue和containsKey。因為contains方法容易讓人引起誤解。
Hashtable繼承自Dictionary類，而HashMap是Java1.2引進的Map interface的一個實現。
最大的不同是，Hashtable的方法是Synchronize的，而HashMap不是，在多個線程訪問Hashtable時，不需要自己為它的方法實現同步，而HashMap 就必須為之提供外同步。
Hashtable和HashMap採用的hash/rehash演算法都大概一樣，所以性能不會有很大的差異。

public static void main(String args[])
{
HashTable h=new HashTable();
h.put("用戶1",new Integer(90));
h.put("用戶2",new Integer(50));
h.put("用戶3",new Integer(60));
h.put("用戶4",new Integer(70));
h.put("用戶5",new Integer(80));
Enumeration e=h.elements();
while(e.hasMoreElements()){
System.out.println(e.nextElement());
}

map 的方法：

clear()從 Map 中刪除所有映射

remove(Object key)從 Map 中刪除鍵和關聯的值

put(Object key, Object value)將指定值與指定鍵相關聯

get(Object key)返回與指定鍵關聯的值

containsKey(Object key)如果 Map 包含指定鍵的映射，則返回 true

containsValue(Object value)如果此 Map 將一個或多個鍵映射到指定值，則返回 true

isEmpty()如果 Map 不包含鍵-值映射，則返回 true size()返回 Map 中的鍵-值映射的數目

這些都代表了Java中的集合，這里主要從其元素是否有序，是否可重復來進行區別記憶，以便恰當地使用，當然還存在同步方面的差異，見上一篇相關文章。

有序否

允許元素重復否

Collection

否

是

List

是

是

Set

AbstractSet

否

否

HashSet

TreeSet

是（用二叉樹排序）

Map

AbstractMap

否

使用key-value來映射和存儲數據，Key必須惟一，value可以重復

HashMap

TreeMap

是（用二叉樹排序）

List 介面對Collection進行了簡單的擴充，它的具體實現類常用的有ArrayList和LinkedList。你可以將任何東西放到一個List容器中，並在需要時從中取出。ArrayList從其命名中可以看出它是一種類似數組的形式進行存儲，因此它的隨機訪問速度極快，而LinkedList的內部實現是鏈表，它適合於在鏈表中間需要頻繁進行插入和刪除操作。在具體應用時可以根據需要自由選擇。前面說的Iterator只能對容器進行向前遍歷，而 ListIterator則繼承了Iterator的思想，並提供了對List進行雙向遍歷的方法。

Set介面也是 Collection的一種擴展，而與List不同的時，在Set中的對象元素不能重復，也就是說你不能把同樣的東西兩次放入同一個Set容器中。它的常用具體實現有HashSet和TreeSet類。HashSet能快速定位一個元素，但是你放到HashSet中的對象需要實現hashCode()方法，它使用了前面說過的哈希碼的演算法。而TreeSet則將放入其中的元素按序存放，這就要求你放入其中的對象是可排序的，這就用到了集合框架提供的另外兩個實用類Comparable和Comparator。一個類是可排序的，它就應該實現Comparable介面。有時多個類具有相同的排序演算法，那就不需要在每分別重復定義相同的排序演算法，只要實現Comparator介面即可。集合框架中還有兩個很實用的公用類：Collections和 Arrays。Collections提供了對一個Collection容器進行諸如排序、復制、查找和填充等一些非常有用的方法，Arrays則是對一個數組進行類似的操作。

Map是一種把鍵對象和值對象進行關聯的容器，而一個值對象又可以是一個Map，依次類推，這樣就可形成一個多級映射。對於鍵對象來說，像Set一樣，一個Map容器中的鍵對象不允許重復，這是為了保持查找結果的一致性;如果有兩個鍵對象一樣，那你想得到那個鍵對象所對應的值對象時就有問題了，可能你得到的並不是你想的那個值對象，結果會造成混亂，所以鍵的唯一性很重要，也是符合集合的性質的。當然在使用過程中，某個鍵所對應的值對象可能會發生變化，這時會按照最後一次修改的值對象與鍵對應。對於值對象則沒有唯一性的要求。你可以將任意多個鍵都映射到一個值對象上，這不會發生任何問題（不過對你的使用卻可能會造成不便，你不知道你得到的到底是那一個鍵所對應的值對象）。Map有兩種比較常用的實現： HashMap和TreeMap。HashMap也用到了哈希碼的演算法，以便快速查找一個鍵，TreeMap則是對鍵按序存放，因此它便有一些擴展的方法，比如firstKey(),lastKey()等，你還可以從TreeMap中指定一個范圍以取得其子Map。鍵和值的關聯很簡單，用pub (Object key,Object value)方法即可將一個鍵與一個值對象相關聯。用get(Object key)可得到與此key對象所對應的值對象。

⑸ java分布式架構有哪些技術

既然是分布式系統，系統間通信的技術就不可避免的要掌握。

首先，我們必須掌握一些基本知識，例如網路通信協議（例如TCP / UDP等），網路IO（Blocking-IO，NonBlocking-IO，Asyn-IO），網卡（多隊列等）。 了解有關連接重用，序列化/反序列化，RPC，負載平衡等的信息。

在學習了這些基本知識之後，您基本上可以在分布式系統中編寫一個簡單的通信模塊，但這實際上還遠遠不夠。 現在，您已經進入了分布式欄位，您已經對規模有很多要求。 這意味著需要一種通信程序，該程序可以支持大量連接，高並發性和低資源消耗。

大量的連接通常會有兩種方式：

大量client連一個server

當前在NonBlocking-IO非常成熟的情況下，支持大量客戶端的伺服器並不難編寫，但是在大規模且通常是長連接的情況下，有一點需要特別注意 ，即伺服器掛起時不可能所有客戶端都在某個時間點啟動重新連接。 那基本上是一場災難。 我見過一些沒有經驗的類似案例。 客戶端規模擴大後，伺服器基本上會在重新啟動後立即刷新。 大量傳入連接中斷（當然，伺服器的積壓隊列首先應設置為稍大一些）。 可以使用的通常方法是在客戶端重新連接之前睡眠一段隨機的時間。 另外，重連間隔採用避讓演算法。

一個client連大量的server

有些場景也會出現需要連大量server的現象，在這種情況下，同樣要注意的也是不要並發同時去建所有的連接，而是在能力范圍內分批去建。

除了建連接外，另外還要注意的地方是並發發送請求也同樣，一定要做好限流，否則很容易會因為一些點慢導致內存爆掉。

這些問題在技術風險上得考慮進去，並在設計和代碼實現上體現，否則一旦隨著規模上去了，問題一時半會還真不太好解。

高並發這個點需要掌握CAS、常見的lock-free演算法、讀寫鎖、線程相關知識（例如線程交互、線程池）等，通信層面的高並發在NonBlocking-IO的情況下，最重要的是要注意在整體設計和代碼實現上盡量減少對io線程池的時間佔用。

低資源消耗這點的話NonBlocking-IO本身基本已經做到。

伸縮性

分布式系統基本上意味著規模不小。 對於此類系統，在設計時必須考慮可伸縮性。 在體系結構圖上繪制的任何點，如果請求量或數據量繼續增加，該怎麼辦？ 通過添加機器來解決。 當然，此過程不需要考慮無限的情況。 如果您有經驗的建築師，從相對較小的規模到非常大型的范圍，那麼優勢顯然並不小，而且它們也將越來越稀缺。 。

橫向可擴展性（Scale Out）是指通過增加伺服器數量來提高群集的整體性能。 垂直可伸縮性（Scale Up）是指提高每台伺服器的性能以提高集群的整體性能。 縱向可擴展性的上限非常明顯，而分布式系統則強調水平可伸縮性。

分布式系統應用服務最好做成無狀態的

應用服務的狀態是指運行時程序因為處理服務請求而存在內存的數據。分布式應用服務最好是設計成無狀態。因為如果應用程序是有狀態的，那麼一旦伺服器宕機就會使得應用服務程序受影響而掛掉，那存在內存的數據也就丟失了，這顯然不是高可靠的服務。把應用服務設計成無狀態的，讓程序把需要保存的數據都保存在專門的存儲上(eg. 資料庫)，這樣應用服務程序可以任意重啟而不丟失數據，方便分布式系統在伺服器宕機後恢復應用服務。

伸縮性的問題圍繞著以下兩種場景在解決：

無狀態場景

對於無狀態場景，要實現隨量增長而加機器支撐會比較簡單，這種情況下只用解決節點發現的問題，通常只要基於負載均衡就可以搞定，硬體或軟體方式都有；

無狀態場景通常會把很多狀態放在db，當量到一定階段後會需要引入服務化，去緩解對db連接數太多的情況。

有狀態場景

所謂狀態其實就是數據，通常採用Sharding來實現伸縮性，Sharding有多種的實現方式，常見的有這么一些：

2.1 規則Sharding

基於一定規則把狀態數據進行Sharding，例如分庫分表很多時候採用的就是這樣的，這種方式支持了伸縮性，但通常也帶來了很復雜的管理、狀態數據搬遷，甚至業務功能很難實現的問題，例如全局join，跨表事務等。

2.2 一致性Hash

一致性Hash方案會使得加機器代價更低一些，另外就是壓力可以更為均衡，例如分布式cache經常採用，和規則Sharding帶來的問題基本一樣。

2.3 Auto Sharding

Auto Sharding的好處是基本上不用管數據搬遷，而且隨著量上漲加機器就OK，但通常Auto Sharding的情況下對如何使用會有比較高的要求，而這個通常也就會造成一些限制，這種方案例如HBase。

2.4 Copy

Copy這種常見於讀遠多於寫的情況，實現起來又會有最終一致的方案和全局一致的方案，最終一致的多數可通過消息機制等，全局一致的例如zookeeper/etcd之類的，既要全局一致又要做到很高的寫支撐能力就很難實現了。

即使發展到今天，Sharding方式下的伸縮性問題仍然是很大的挑戰，非常不好做。

上面所寫的基本都還只是解決的方向，到細節點基本就很容易判斷是一個解決過多大規模場景問題的架構師，:)

穩定性

作為分布式系統，必須要考慮清楚整個系統中任何一個點掛掉應該怎麼處理（到了一定機器規模，每天掛掉一些機器很正常），同樣主要還是分成了無狀態和有狀態：

無狀態場景

對於無狀態場景，通常好辦，只用節點發現的機制上具備心跳等檢測機制就OK，經驗上來說無非就是純粹靠4層的檢測對業務不太夠，通常得做成7層的，當然，做成7層的就得處理好規模大了後的問題。

有狀態場景

對於有狀態場景，就比較麻煩了，對數據一致性要求不高的還OK，主備類型的方案基本也可以用，當然，主備方案要做的很好也非常不容易，有各種各樣的方案，對於主備方案又覺得不太爽的情況下，例如HBase這樣的，就意味著掛掉一台，另外一台接管的話是需要一定時間的，這個對可用性還是有一定影響的；

全局一致類型的場景中，如果一台掛了，就通常意味著得有選舉機制來決定其他機器哪台成為主，常見的例如基於paxos的實現。

可維護性

維護性是很容易被遺漏的部分，但對分布式系統來說其實是很重要的部分，例如整個系統環境應該怎麼搭建，部署，配套的維護工具、監控點、報警點、問題定位、問題處理策略等等。

⑹ java里equals和hashCode之間什麼關系

1. 首先equals()和hashcode()這兩個方法都是從object類中繼承過來的。
equals()方法在object類中定義如下：
public boolean equals(Object obj) {
return (this == obj);
}
很明顯是對兩個對象的地址值進行的比較（即比較引用是否相同）。但是我們必需清楚，當String 、Math、還有Integer、Double。。。。等這些封裝類在使用equals()方法時，已經覆蓋了object類的equals（）方法。比如在String類中如下：
public boolean equals(Object anObject) {
if (this == anObject) {
return true;
}
if (anObject instanceof String) {
String anotherString = (String)anObject;
int n = count;
if (n == anotherString.count) {
char v1[] = value;
char v2[] = anotherString.value;
int i = offset;
int j = anotherString.offset;
while (n-- != 0) {
if (v1[i++] != v2[j++])
return false;
}
return true;
}
}
return false;
}
很明顯，這是進行的內容比較，而已經不再是地址的比較。依次類推Double、Integer、Math。。。。等等這些類都是重寫了equals()方法的，從而進行的是內容的比較。當然了基本類型是進行值的比較，這個沒有什麼好說的。
我們還應該注意，Java語言對equals()的要求如下，這些要求是必須遵循的：
�6�1 對稱性：如果x.equals(y)返回是「true」，那麼y.equals(x)也應該返回是「true」。
�6�1 反射性：x.equals(x)必須返回是「true」。
�6�1 類推性：如果x.equals(y)返回是「true」，而且y.equals(z)返回是「true」，那麼z.equals(x)也應該返回是「true」。
�6�1 還有一致性：如果x.equals(y)返回是「true」，只要x和y內容一直不變，不管你重復x.equals(y)多少次，返回都是「true」。
�6�1 任何情況下，x.equals(null)，永遠返回是「false」；x.equals(和x不同類型的對象)永遠返回是「false」。
以上這五點是重寫equals()方法時，必須遵守的准則，如果違反會出現意想不到的結果，請大家一定要遵守。
2. 其次是hashcode() 方法，在object類中定義如下：
public native int hashCode();
說明是一個本地方法，它的實現是根據本地機器相關的。當然我們可以在自己寫的類中覆蓋hashcode()方法，比如String、Integer、Double。。。。等等這些類都是覆蓋了hashcode()方法的。例如在String類中定義的hashcode()方法如下：
public int hashCode() {
int h = hash;
if (h == 0) {
int off = offset;
char val[] = value;
int len = count;

for (int i = 0; i < len; i++) {
h = 31*h + val[off++];
}
hash = h;
}
return h;
}
解釋一下這個程序（String的API中寫到）：
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
使用 int 演算法，這里 s[i] 是字元串的第 i 個字元，n 是字元串的長度，^ 表示求冪。（空字元串的哈希碼為 0。）
首先，想要明白hashCode的作用，你必須要先知道Java中的集合。
總的來說，Java中的集合（Collection）有兩類，一類是List，再有一類是Set。
你知道它們的區別嗎？前者集合內的元素是有序的，元素可以重復；後者元素無序，但元素不可重復。
那麼這里就有一個比較嚴重的問題了：要想保證元素不重復，可兩個元素是否重復應該依據什麼來判斷呢？
這就是Object.equals方法了。但是，如果每增加一個元素就檢查一次，那麼當元素很多時，後添加到集合中的元素比較的次數就非常多了。
也就是說，如果集合中現在已經有1000個元素，那麼第1001個元素加入集合時，它就要調用1000次equals方法。這顯然會大大降低效率。
於是，Java採用了哈希表的原理。哈希（Hash）實際上是個人名，由於他提出一哈希演算法的概念，所以就以他的名字命名了。
哈希演算法也稱為散列演算法，是將數據依特定演算法直接指定到一個地址上。如果詳細講解哈希演算法，那需要更多的文章篇幅，我在這里就不介紹了。
初學者可以這樣理解，hashCode方法實際上返回的就是對象存儲的物理地址（實際可能並不是）。
這樣一來，當集合要添加新的元素時，先調用這個元素的hashCode方法，就一下子能定位到它應該放置的物理位置上。
如果這個位置上沒有元素，它就可以直接存儲在這個位置上，不用再進行任何比較了；如果這個位置上已經有元素了，
就調用它的equals方法與新元素進行比較，相同的話就不存了，不相同就散列其它的地址。
所以這里存在一個沖突解決的問題。這樣一來實際調用equals方法的次數就大大降低了，幾乎只需要一兩次。
所以，Java對於eqauls方法和hashCode方法是這樣規定的：
1、如果兩個對象相同，那麼它們的hashCode值一定要相同；2、如果兩個對象的hashCode相同，它們並不一定相同 上面說的對象相同指的是用eqauls方法比較。
你當然可以不按要求去做了，但你會發現，相同的對象可以出現在Set集合中。同時，增加新元素的效率會大大下降。
3.這里我們首先要明白一個問題：
equals()相等的兩個對象，hashcode()一定相等；
equals（）不相等的兩個對象，卻並不能證明他們的hashcode()不相等。換句話說，equals()方法不相等的兩個對象，hashcode()有可能相等。（我的理解是由於哈希碼在生成的時候產生沖突造成的）。
反過來：hashcode()不等，一定能推出equals()也不等；hashcode()相等，equals()可能相等，也可能不等。解釋下第3點的使用范圍，我的理解是在object、String等類中都能使用。在object類中，hashcode()方法是本地方法，返回的是對象的地址值，而object類中的equals()方法比較的也是兩個對象的地址值，如果equals()相等，說明兩個對象地址值也相等，當然hashcode()也就相等了；在String類中，equals()返回的是兩個對象內容的比較，當兩個對象內容相等時，
Hashcode()方法根據String類的重寫（第2點裡面已經分析了）代碼的分析，也可知道hashcode()返回結果也會相等。以此類推，可以知道Integer、Double等封裝類中經過重寫的equals()和hashcode()方法也同樣適合於這個原則。當然沒有經過重寫的類，在繼承了object類的equals()和hashcode()方法後，也會遵守這個原則。

4.談到hashcode()和equals()就不能不說到hashset,hashmap,hashtable中的使用，具體是怎樣呢，請看如下分析：
Hashset是繼承Set介面，Set介面又實現Collection介面，這是層次關系。那麼hashset是根據什麼原理來存取對象的呢？
在hashset中不允許出現重復對象，元素的位置也是不確定的。在hashset中又是怎樣判定元素是否重復的呢？這就是問題的關鍵所在，經過一下午的查詢求證終於獲得了一點啟示，和大家分享一下，在java的集合中，判斷兩個對象是否相等的規則是：
1)，判斷兩個對象的hashCode是否相等
如果不相等，認為兩個對象也不相等，完畢
如果相等，轉入2)
（這一點只是為了提高存儲效率而要求的，其實理論上沒有也可以，但如果沒有，實際使用時效率會大大降低，所以我們這里將其做為必需的。後面會重點講到這個問題。）
2)，判斷兩個對象用equals運算是否相等
如果不相等，認為兩個對象也不相等
如果相等，認為兩個對象相等（equals()是判斷兩個對象是否相等的關鍵）
為什麼是兩條准則，難道用第一條不行嗎？不行，因為前面已經說了，hashcode()相等時，equals()方法也可能不等，所以必須用第2條准則進行限制，才能保證加入的為非重復元素。
比如下面的代碼：

public static void main(String args[]){
String s1=new String("zhaoxudong");
String s2=new String("zhaoxudong");
System.out.println(s1==s2);//false
System.out.println(s1.equals(s2));//true
System.out.println(s1.hashCode());//s1.hashcode()等於s2.hashcode()
System.out.println(s2.hashCode());
Set hashset=new HashSet();
hashset.add(s1);
hashset.add(s2);
/*實質上在添加s1,s2時，運用上面說到的兩點准則，可以知道hashset認為s1和s2是相等的，是在添加重復元素，所以讓s2覆蓋了s1;*/
Iterator it=hashset.iterator();
while(it.hasNext())
{
System.out.println(it.next());
}
最後在while循環的時候只列印出了一個」zhaoxudong」。
輸出結果為：false
true
-967303459
-967303459
這是因為String類已經重寫了equals()方法和hashcode()方法，所以在根據上面的第1.2條原則判定時，hashset認為它們是相等的對象，進行了重復添加。
但是看下面的程序：
import java.util.*;
public class HashSetTest
{
public static void main(String[] args)
{
HashSet hs=new HashSet();
hs.add(new Student(1,"zhangsan"));
hs.add(new Student(2,"lisi"));
hs.add(new Student(3,"wangwu"));
hs.add(new Student(1,"zhangsan"));

Iterator it=hs.iterator();
while(it.hasNext())
{
System.out.println(it.next());
}
}
}
class Student
{
int num;
String name;
Student(int num,String name)
{
this.num=num;
this.name=name;
}
public String toString()
{
return num+":"+name;
}
}
輸出結果為：
1:zhangsan
1:zhangsan
3:wangwu
2:lisi
問題出現了，為什麼hashset添加了相等的元素呢，這是不是和hashset的原則違背了呢？回答是：沒有
因為在根據hashcode()對兩次建立的new Student(1,"zhangsan")對象進行比較時，生成的是不同的哈希碼值，所以hashset把他當作不同的對象對待了，當然此時的equals()方法返回的值也不等（這個不用解釋了吧）。那麼為什麼會生成不同的哈希碼值呢？上面我們在比較s1和s2的時候不是生成了同樣的哈希碼嗎？原因就在於我們自己寫的Student類並沒有重新自己的hashcode()和equals()方法，所以在比較時，是繼承的object類中的hashcode()方法，呵呵，各位還記得object類中的hashcode()方法比較的是什麼吧！！
它是一個本地方法，比較的是對象的地址（引用地址），使用new方法創建對象，兩次生成的當然是不同的對象了（這個大家都能理解吧。。。），造成的結果就是兩個對象的hashcode()返回的值不一樣。所以根據第一個准則，hashset會把它們當作不同的對象對待，自然也用不著第二個准則進行判定了。那麼怎麼解決這個問題呢？？
答案是：在Student類中重新hashcode()和equals()方法。
例如：
class Student
{
int num;
String name;
Student(int num,String name)
{
this.num=num;
this.name=name;
}
public int hashCode()
{
return num*name.hashCode();
}
public boolean equals(Object o)
{
Student s=(Student)o;
return num==s.num && name.equals(s.name);
}
public String toString()
{
return num+":"+name;
}
}
根據重寫的方法，即便兩次調用了new Student(1,"zhangsan")，我們在獲得對象的哈希碼時，根據重寫的方法hashcode()，獲得的哈希碼肯定是一樣的（這一點應該沒有疑問吧）。
當然根據equals()方法我們也可判斷是相同的。所以在向hashset集合中添加時把它們當作重復元素看待了。所以運行修改後的程序時，我們會發現運行結果是：
1:zhangsan
3:wangwu
2:lisi
可以看到重復元素的問題已經消除。
關於在hibernate的pojo類中，重新equals()和hashcode()的問題：
1)，重點是equals，重寫hashCode只是技術要求（為了提高效率）
2)，為什麼要重寫equals呢，因為在java的集合框架中，是通過equals來判斷兩個對象是否相等的
3)，在hibernate中，經常使用set集合來保存相關對象，而set集合是不允許重復的。我們再來談談前面提到在向hashset集合中添加元素時,怎樣判斷對象是否相同的准則，前面說了兩條，其實只要重寫equals()這一條也可以。
但當hashset中元素比較多時，或者是重寫的equals()方法比較復雜時，我們只用equals()方法進行比較判斷，效率也會非常低，所以引入了hashcode()這個方法，只是為了提高效率，但是我覺得這是非常有必要的（所以我們在前面以兩條准則來進行hashset的元素是否重復的判斷）。
比如可以這樣寫：
public int hashCode(){
return 1;}//等價於hashcode無效
這樣做的效果就是在比較哈希碼的時候不能進行判斷，因為每個對象返回的哈希碼都是1，每次都必須要經過比較equals()方法後才能進行判斷是否重復，這當然會引起效率的大大降低。
我有一個問題，如果像前面提到的在hashset中判斷元素是否重復的必要方法是equals()方法（根據網上找到的觀點），但是這里並沒有涉及到關於哈希表的問題，可是這個集合卻叫hashset，這是為什麼？？
我想，在hashmap,hashtable中的存儲操作，依然遵守上面的准則。所以這里不再多說。這些是今天看書，網上查詢資料，自己總結出來的，部分代碼和語言是引述，但是千真萬確是自己總結出來的。有錯誤之處和不詳細不清楚的地方還請大家指出，我也是初學者，所以難免會有錯誤的地方，希望大家共同討論。

⑺ java怎樣實現手寫簽章

熟練使用各種數據結構和演算法，數組、哈希、鏈表、排序樹…，一句話要麼是時間換空間要麼是空間換時間，這里展開可以說一大堆，需要有一定的應用經驗，用於解決各種性能或業務上的問題。
熟練使用linux操作系統，必備，沒什麼好說的 。

熟悉tcp協議，創建連接三次握手和斷開連接四次握手的整個過程，不了解的話，無法對高並發網路應用做優化; 熟悉http協議，尤其是http頭，我發現好多工作五年以上的都弄不清session和cookie的生命周期以及它們之間的關聯。

系統集群、負載均衡、反向代理、動靜分離，網站靜態化 。

分布式存儲系統nfs,fastdfs,tfs,Hadoop了解他們的優缺點，適用場景 。

分布式緩存技術memcached,redis，提高系統性能必備，一句話，把硬碟上的內容放到內存里來提速，順便提個演算法一致性hash 。

工具nginx必備技能超級好用，高性能，基本不會掛掉的伺服器，功能多多，解決各種問題。

資料庫的設計能力，mysql必備，最基礎的資料庫工具，免費好用，對它基本的參數優化，慢查詢日誌分析，主從復制的配置，至少要成為半個mysql dba。其他nosql資料庫如mongodb。

⑻ java中值相同，hashcode一定相同嗎

兩者之間唯一的必然關系被你說反了，equls返回為true,則兩者的hashcode一定相等，意即相等的對象必須具有相等的哈希碼。每當equals方法被覆寫，通常需要重寫hashCode方法從而
保持對象行為的一致性。而具有相等的hashcode的兩個對象equals不一定成立。你可以這樣認為也行，hashcode是作為一個對象存儲的參考，hash表本身是一種散列表，在數據存儲這塊，功效比較大，而equals是相當於兩對象之間的屬性（成員變數）「相等」，意即具有相同的行為（方法）。或許這樣講起來理解比較的費勁。舉個例子，比如你定義class A有兩個屬性，int aA,aB,在定義一個class B也有兩個屬性，int bA,bB,然後覆寫hashcode方法，A類為return aA*aB;B類為return bA*bB.現在情況已經很顯然了，各自實例化一個對象:a,b,假如:a.aA=b.bA,a.aB=b.bB,相等，或者a.aA=b.bB,a.aB=b.bA兩個對象a,b的hashcode一定相等，當時你能說兩個對象相等嗎？顯然不能吧，a與b都是不同類的實例。連equals最基本的obj instance of A或是obj instance of B都不成立。如果是同一個類的不同對象，當兩者擁有相同hashcode的時候，則一定相等，或者equals成立的時候則hashcode一定為真，這也就是所謂的相等的對象具有行為一致性。

⑼ java中哪些地方實現了一致性hash演算法

關於一致性Hash演算法，在我之前的博文中已經有多次提到了，MemCache超詳細解讀一文中"一致性Hash演算法"部分，對於為什麼要使用一致性Hash演算法、一致性Hash演算法的演算法原理做了詳細的解讀。

演算法的具體原理這里再次貼上：

先構造一個長度為232的整數環（這個環被稱為一致性Hash環），根據節點名稱的Hash值（其分布為[0, 232-1]）將伺服器節點放置在這個Hash環上，然後根據數據的Key值計算得到其Hash值（其分布也為[0, 232-1]），接著在Hash環上順時針查找距離這個Key值的Hash值最近的伺服器節點，完成Key到伺服器的映射查找。

這種演算法解決了普通余數Hash演算法伸縮性差的問題，可以保證在上線、下線伺服器的情況下盡量有多的請求命中原來路由到的伺服器。

當然，萬事不可能十全十美，一致性Hash演算法比普通的余數Hash演算法更具有伸縮性，但是同時其演算法實現也更為復雜，本文就來研究一下，如何利用Java代碼實現一致性Hash演算法。在開始之前，先對一致性Hash演算法中的幾個核心問題進行一些探究。

⑽ 一致性哈希 java實現 怎麼映射到圓環上

一致性哈希提出了在動態變化的Cache環境中，哈希演算法應該滿足的4個適應條件：單調性是指如果已經有一些內容通過哈希分派到了相應的緩沖中，又有新的緩沖區加入到系統中，那麼哈希的結果應能夠保證原有已分配的內容可以被映射到新的緩沖區中去，而不會被映射到舊的緩沖集合中的其他緩沖區。（這段翻譯信息有負面價值的，當緩沖區大小變化時一致性哈希(Consistenthashing)盡量保護已分配的內容不會被重新映射到新緩沖區。）簡單的哈希演算法往往不能滿足單調性的要求，如最簡單的線性哈希：x→ax+bmod(P)在上式中，P表示全部緩沖的大小。不難看出，當緩沖大小發生變化時(從P1到P2)，原來所有的哈希結果均會發生變化，從而不滿足單調性的要求。哈希結果的變化意味著當緩沖空間發生變化時，所有的映射關系需要在系統內全部更新。而在P2P系統內，緩沖的變化等價於Peer加入或退出系統，這一情況在P2P系統中會頻繁發生，因此會帶來極大計算和傳輸負荷。單調性就是要求哈希演算法能夠應對這種情況。負載問題實際上是從另一個角度看待分散性問題。既然不同的終端可能將相同的內容映射到不同的緩沖區中，那麼對於一個特定的緩沖區而言，也可能被不同的用戶映射為不同的內容。與分散性一樣，這種情況也是應當避免的，因此好的哈希演算法應能夠盡量降低緩沖的負荷。從表面上看，一致性哈希針對的是分布式緩沖的問題，但是如果將緩沖看作P2P系統中的Peer，將映射的內容看作各種共享的資源(數據，文件，媒體流等)，就會發現兩者實際上是在描述同一問題。路由演算法在一致性哈希演算法中，每個節點(對應P2P系統中的Peer)都有隨機分配的ID。在將內容映射到節點時，使用內容的關鍵字和節點的ID進行一致性哈希運算並獲得鍵值。一致性哈希要求鍵值和節點ID處於同一值域。最簡單的鍵值和ID可以是一維的，比如從0000到9999的整數集合。根據鍵值存儲內容時，內容將被存儲到具有與其鍵值最接近的ID的節點上。例如鍵值為1001的內容，系統中有ID為1000，1010，1100的節點，該內容將被映射到1000節點。為了構建查詢所需的路由，一致性哈希要求每個節點存儲其上行節點(ID值大於自身的節點中最小的)和下行節點(ID值小於自身的節點中最大的)的位置信息(IP地址)。當節點需要查找內容時，就可以根據內容的鍵值決定向上行或下行節點發起查詢請求。收到查詢請求的節點如果發現自己擁有被請求的目標，可以直接向發起查詢請求的節點返回確認；如果發現不屬於自身的范圍，可以轉發請求到自己的上行/下行節點。為了維護上述路由信息，在節點加入/退出系統時，相鄰的節點必須及時更新路由信息。這就要求節點不僅存儲直接相連的下行節點位置信息，還要知道一定深度(n跳)的間接下行節點信息，並且動態地維護節點列表。當節點退出系統時，它的上行節點將嘗試直接連接到最近的下行節點，連接成功後，從新的下行節點獲得下行節點列表並更新自身的節點列表。同樣的，當新的節點加入到系統中時，首先根據自身的ID找到下行節點並獲得下行節點列表，然後要求上行節點修改其下行節點列表，這樣就恢復了路由關系。