这是一个创建于 2207 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如我看 hashmap 源码就发现很花时间，有很多细节容易看进去了(红黑树那块也看了好久，但就算能看懂，以后让我手撕估计也是不行的)。
虽然我也想处处都精看，但奈何时间有限。所以想问问各位在看源码时，有没有什么独到的侧重点和方法？
虽然我也想处处都精看，但奈何时间有限。所以想问问各位在看源码时，有没有什么独到的侧重点和方法？
 | 1 forgottencoast 2019-12-25 09:33:25 +08:00 via iPhone 一般先看别人的介绍文章，再看就轻松多了。 |
 | 2 amiwrong123 OP @forgottencoast 是啊，肯定是要看别人的博客的。但有时候别人博客也不是很仔细，上次有个 balanceInsertion 的疑问，百度了一圈没有解决疑问，谷歌后更神奇，好像国外没有程序员在研究 hashmap 的红黑树操作似的 |
 | 3 securityCoding 2019-12-25 09:48:04 +08:00 最近一直在思考一个问题：如何知道自己真的懂了？挺有意思建议楼主也思考思考 |
 | 4 Michaelssss 2019-12-25 09:54:49 +08:00 问面试官你要问哪个源码，现场搬出电脑一起看。。 |
| 5 amiwrong123 OP @securityCoding 这个确实值得思考，现在就是看完了写博客，强迫自己整理思路，我觉得这样会让自己更懂吧 |
| 6 amiwrong123 OP @Michaelssss 哈哈哈，面试官说：你给回家看去 |
 |
 | 8 guxingke 2019-12-25 10:37:03 +08:00 面向面试的话, 那就关心相关的面试题, 带着问题, 从源码里找答案. 总结之. |
| 9 securityCoding 2019-12-25 11:57:25 +08:00 @amiwrong123 应该到能用自己组织的语言简单的表达出来才算看懂，可以看看 YJango 这位 B 站 up 主的视频 |
 | 10 vjnjc 2019-12-25 12:05:49 +08:00 面向问题看啊，比如 hashmap 怎么实现 get 效率在 o （ 1 ）的，并发性问题怎么产生的，要是你来设计怎么修复 |
 | 11 vwym 2019-12-25 14:25:26 +08:00 面试有一个好处，唬住 50K，唬不住 5K，更重要还是看你当时的口才，练表达能力应该更加有效。 给个建议，把源码阅读写下来，尽量写成能让看的人通俗易懂，放到自己的个人博客里面。 至少唬不住的时候还能够说不太记得，但是当时是分析了巴拉巴拉的。 |
 | 12 hatcloud 2019-12-25 14:53:32 +08:00 我问 Hashmap 实现原理的时候，其实不太关心你是不是知道红黑树什么的，更想知道的，为什么要这么设计。知道细节是加分项，知道代码解决的是什么问题，为什么这么设计是好的，才决定我觉得这个人是否是我想共事的同事。 |
| 13 hatcloud 2019-12-25 15:09:57 +08:00  2 所以我觉得面对面试看源码可以着重看源码的结构设计，不同部分之间交互的设计模式。整个大框架看明白了后，再看细节。 突然想到陶渊明说的「不求甚解」。如果时间和精力是无限的话，扣的细没什么不好，但偏偏没人的时间和精力是无限的。 回到楼主的主题，我觉得去探究 hashmap 里面红黑树的具体实现肯定是很好的求知精神，但就「面向面试」这个命题而言，我觉得是没必要的。这些时间可以拿去看更多的其他知识点。不过，都是浅尝则止也不好，会让面试官有个「深度不够」这样的印象，所以肯定需要有些地方是细看的。至于哪些地方细看，我觉得应该是和自己项目经验结合的地方。比如项目中自己碰到了很多内存相关的问题，那 JVM 的内存回收的细节是需要细细看的，又比如如果自己做的是一个需要大量加载图片的 App，那么 Bitmap 相关的知识就是逃不掉的。和项目经验结合，这些细节看起来可以和之前的经验交相验证，也会比生啃其他知识点的细节要轻松一些，同时和例子一起讲，在面试的时候更能折服面试官。 |
Select Language