浏览:2612008-04-27 01:14   来自abatei      :

老大的书很棒,正在看,有个小小的疑问 

357页的第5行:

"程序接着运行,JIT根据"abcdef"在哈希表中逐个查找,结果找到了该字符串"

如果是逐个查找,那也就失去了哈希表的意义。感觉应该是先计算机“abcdef”的哈希码,再通过哈希码计算查找。我也不知道正确答案,只是推测。提出来希望讨论下。

另外一直对这个哈希表的key和value有些疑问,356页的图8-1中,key存放的是字符串,由于哈希表的每个元素必须占用相同的空间,而字符串有长有短,也就是说key里面存放的只可能是指向这个字符串的指针,而value本身也是指向字符串对象的指针。两者内容雷同,感觉多余,也不合逻辑。但Jeffrey Richter在《框架设计》中明确指出key存的是字符串,value指向托管堆中的字符串对象,上网查也是相同的答案。希望老大可以帮我解开心中疑团。

楼主
  2个月前   Anytao      :
很高兴收到你的疑问和讨论,也引起了我的兴趣和思考,关于这两个问题:

关于第一个问题,属于我的大意,JIT在查找内部哈希表结构时,的确是按照“abcdef”的Hash Code进行的,书中表述未清,我会及时在勘误中指明,也谢谢你的提醒。这一点可以从查看Reflector中得到例证,String.Intern方法在内部调用的是当前线程AppDomain的GetOrInternString方法:
return Thread.GetDomain().GetOrInternString(str);
而在该方法内部则是根据字符串内容计算出Hash Code进行比较的。

关于第二个问题,CLR内部维护者一个称为“Intern Pool”的哈希表结构,Key保持String本身,Value保存string在托管堆中的引用地址,这一点毋庸置疑。书中图例表达的是对上述过程的模拟。

而对于“哈希表的每个元素必须占用相同的空间”的说法,恕我不解,望指教:-)
回复  1楼 回到顶楼 
  2个月前   abatei      :
呵呵,多谢老大能回答这个问题。我也是对此持有怀疑态度,很希望能解开心中疑惑。下面说说我的看法。
哈希表本身也是一个数组,之所以能快速查找,是因为它可以通过key计算出一个哈希码,然后再用这个哈希码计算出这条记录在数组中的索引号,从而可以根据这个索引号快速定位。数组之所以可以快速定位,就是因为它的每个元素所占用的空间是一样而且是顺序存储的。比如第一个元素的地址是2000,每个元素占用32个位,那么索引为5的元素的内存地址可以马上计算出来。即:2000+5*32=2160
如果每个元素所占用的空间不同,那么是不可能进行快速定位的。所以我就产生了疑惑。
回复  2楼 回到顶楼 

你还不是小组成员,加入小组以后才能发布新主题!
1 29896