1. import java.util.*;
   
2. class LinkedListDemo
   
3. {
   
4.         public int hashCode()
   
5.         {
   
6.                 return 99;
   
7.         }
   
8.         public static void main(String[] args)
   
9.         {
   
10.                 LinkedListDemo lld = new LinkedListDemo();//哈希值是99
    
11.                 LinkedListDemo lldd = new LinkedListDemo();//哈希值是99
    
12.                 System.out.println(lld);
    
13.                 System.out.println(lldd);
    
14.         }
    
15. }

复制代码

不明白，两个或多个对象怎么能共用一个哈希值呢？它们究竟是怎么存储的？

public int hashCode() 这个已经说的很清楚了
hashCode 只是一个方法的返回值，更进一步来说，只是一个 int型 整数
跟存储其实没什么关系，说hashCode用于存储是说Hashtable这种无序数据存储方式采用hashCode作为存储参数，使用一个天书一般的算法实现
其实如果类不实现hashtable的话hashcode的作用不是很明显
一般说重写equals方法时也要重写hashcode只是为了遵循hash约定

每个自定义类都继承自Object，LinkedListDemo重写hashcode()方法之后就是调用自己的方法了，返回都是99，直接打印的话就是哈希值，一般hashcode()计算出的值为jvm中内存地址，上面的LinkedListDemo自定义后就是99，至于hashcode()底层是怎么计算出来的，可以参考java的源代码：

1. intptr_t ObjectSynchronizer::FastHashCode (Thread * Self, oop obj) {
   
2.   if (UseBiasedLocking) {
   
3.     // NOTE: many places throughout the JVM do not expect a safepoint
   
4.     // to be taken here, in particular most operations on perm gen
   
5.     // objects. However, we only ever bias Java instances and all of
   
6.     // the call sites of identity_hash that might revoke biases have
   
7.     // been checked to make sure they can handle a safepoint. The
   
8.     // added check of the bias pattern is to avoid useless calls to
   
9.     // thread-local storage.
   
10.     if (obj->mark()->has_bias_pattern()) {
    
11.       // Box and unbox the raw reference just in case we cause a STW safepoint.
    
12.       Handle hobj (Self, obj) ;         
    
13.       // Relaxing assertion for bug 6320749.
    
14.       assert (Universe::verify_in_progress() ||
    
15.               !SafepointSynchronize::is_at_safepoint(),
    
16.              "biases should not be seen by VM thread here");
    
17.       BiasedLocking::revoke_and_rebias(hobj, false, JavaThread::current());
    
18.       obj = hobj() ;
    
19.       assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now");
    
20.     }
    
21.   }
    
22. 
    
23.   // hashCode() is a heap mutator ...
    
24.   // Relaxing assertion for bug 6320749.
    
25.   assert (Universe::verify_in_progress() ||
    
26.           !SafepointSynchronize::is_at_safepoint(), "invariant") ;
    
27.   assert (Universe::verify_in_progress() ||
    
28.           Self->is_Java_thread() , "invariant") ;
    
29.   assert (Universe::verify_in_progress() ||
    
30.          ((JavaThread *)Self)->thread_state() != _thread_blocked, "invariant") ;
    
31. 
    
32.   ObjectMonitor* monitor = NULL;
    
33.   markOop temp, test;
    
34.   intptr_t hash;
    
35.   markOop mark = ReadStableMark (obj);
    
36. 
    
37.   // object should remain ineligible for biased locking
    
38.   assert (!mark->has_bias_pattern(), "invariant") ;
    
39. 
    
40.   if (mark->is_neutral()) {
    
41.     hash = mark->hash();              // this is a normal header
    
42.     if (hash) {                       // if it has hash, just return it
    
43.       return hash;
    
44.     }
    
45.     hash = get_next_hash(Self, obj);  // allocate a new hash code
    
46.     temp = mark->copy_set_hash(hash); // merge the hash code into header
    
47.     // use (machine word version) atomic operation to install the hash
    
48.     test = (markOop) Atomic::cmpxchg_ptr(temp, obj->mark_addr(), mark);
    
49.     if (test == mark) {
    
50.       return hash;
    
51.     }
    
52.     // If atomic operation failed, we must inflate the header
    
53.     // into heavy weight monitor. We could add more code here
    
54.     // for fast path, but it does not worth the complexity.
    
55.   } else if (mark->has_monitor()) {
    
56.     monitor = mark->monitor();
    
57.     temp = monitor->header();
    
58.     assert (temp->is_neutral(), "invariant") ;
    
59.     hash = temp->hash();
    
60.     if (hash) {
    
61.       return hash;
    
62.     }
    
63.     // Skip to the following code to reduce code size
    
64.   } else if (Self->is_lock_owned((address)mark->locker())) {
    
65.     temp = mark->displaced_mark_helper(); // this is a lightweight monitor owned
    
66.     assert (temp->is_neutral(), "invariant") ;
    
67.     hash = temp->hash();              // by current thread, check if the displaced
    
68.     if (hash) {                       // header contains hash code
    
69.       return hash;
    
70.     }
    
71.     // WARNING:
    
72.     //   The displaced header is strictly immutable.
    
73.     // It can NOT be changed in ANY cases. So we have
    
74.     // to inflate the header into heavyweight monitor
    
75.     // even the current thread owns the lock. The reason
    
76.     // is the BasicLock (stack slot) will be asynchronously
    
77.     // read by other threads during the inflate() function.
    
78.     // Any change to stack may not propagate to other threads
    
79.     // correctly.
    
80.   }
    
81. 
    
82.   // Inflate the monitor to set hash code
    
83.   monitor = ObjectSynchronizer::inflate(Self, obj);
    
84.   // Load displaced header and check it has hash code
    
85.   mark = monitor->header();
    
86.   assert (mark->is_neutral(), "invariant") ;
    
87.   hash = mark->hash();
    
88.   if (hash == 0) {
    
89.     hash = get_next_hash(Self, obj);
    
90.     temp = mark->copy_set_hash(hash); // merge hash code into header
    
91.     assert (temp->is_neutral(), "invariant") ;
    
92.     test = (markOop) Atomic::cmpxchg_ptr(temp, monitor, mark);
    
93.     if (test != mark) {
    
94.       // The only update to the header in the monitor (outside GC)
    
95.       // is install the hash code. If someone add new usage of
    
96.       // displaced header, please update this code
    
97.       hash = test->hash();
    
98.       assert (test->is_neutral(), "invariant") ;
    
99.       assert (hash != 0, "Trivial unexpected object/monitor header usage.");
    
100.     }
     
101.   }
     
102.   // We finally get the hash
     
103.   return hash;
     
104. }

复制代码

hashCode()是一本地方法，也就是说当new一个对象的时候，都会有一个hash码，计算hash码用到相应的hash算法，我个人认为之所以hashcode（）方法是一个本地方法，是应为java中的对象的hash码的得出是通过本地系统提供的hash算法（个人理解，有误请指正），还有java中 对象的hashcode并不是指对象的物理地址。你复写hashcode方法后，就是说对象的hashcode是按你写的方法来计算而已，在楼主的程序中你是new了两个对象，所以内存地址肯定是不一样的，但是在你定义的类中复写里hashcode方法，而且是返回一个确定的值，所以他们hash码肯定是一致的。

先给大体介绍一下吧。
Java中的集合（Collection）有两类，一类是List，再有一类是Set。
你知道它们的区别吗？前者集合内的元素是有序的，元素可以重复；后者元素无序，但元素不可重复。
那么这里就有一个比较严重的问题了：要想保证元素不重复，可两个元素是否重复应该依据什么来判断呢？
这就是Object.equals方法了。但是，如果每增加一个元素就检查一次，那么当元素很多时，后添加到集合中的元素比较的次数就非常多了。 也就是说，如果集合中现在已经有1000个元素，那么第1001个元素加入集合时，它就要调用1000次equals方法。这显然会大大降低效率。    于是，Java采用了哈希表的原理。
初学者可以这样理解，hashCode方法实际上返回的就是对象存储的物理地址（实际可能并不是）。   
这样一来，当集合要添加新的元素时，先调用这个元素的hashCode方法，就一下子能定位到它应该放置的物理位置上。
如果这个位置上没有元素，它就可以直接存储在这个位置上，不用再进行任何比较了；如果这个位置上已经有元素了，
就调用它的equals方法与新元素进行比较，相同的话就不存了，不相同就散列其它的地址。
所以这里存在一个冲突解决的问题。这样一来实际调用equals方法的次数就大大降低了，几乎只需要一两次。   
所以，Java对于eqauls方法和hashCode方法是这样规定的：
1、如果两个对象相同，那么它们的hashCode值一定要相同；
2、如果两个对象的hashCode相同，它们并不一定相同     上面说的对象相同指的是用eqauls方法比较。   
你当然可以不按要求去做了，但你会发现，相同的对象可以出现在Set集合中。同时，增加新元素的效率会大大下降。
楼主的问题就是，底层都会调用public int hashCode()方法，楼主自行实现并覆盖了父类hashCode，代码中 return 99; 当然返回99了