神经符号系统、跨学科交互

阿粉给面试官介绍的时候直接就从图上介绍了，而阿粉直接分析源码的时候，刚开始Segment继承了ReentrantLock的时候，面试官就打断了我接下来要叙述的内容，让我直接就说1.8的了。

1.8中的：

• 首先new一个新的hash表(nextTable)出来，大小是原来的2倍。后面的rehash都是针对这个新的hash表操作，不涉及原hash表(table)。
• 然后会对原hash表(table)中的每个链表进行rehash，此时会尝试获取头节点的锁。这一步就保证了在rehash的过程中不能对这个链表执行put操作。
• 通过sizeCtl控制，使扩容过程中不会new出多个新hash表来。
• 最后，将所有键值对重新rehash到新表(nextTable)中后，用nextTable将table替换。这就避免了HashMap中get和扩容并发时，可能get到null的问题。
• 在整个过程中，共享变量的存储和读取全部通过volatile或CAS的方式，保证了线程安全。

而至于分析源码，阿粉不再进行分析了，以后在遇到面试的时候分析源码的时候在继续给大家说。毕竟下面还有很多内容。

面试题2：你对着两种方式的看法是什么，为什么1.8要改变呢?优点是哪里呢?

阿粉就猜测到可能这么问，毕竟你开了头了，你都区分出1.7和1.8了，必然会有面试官会这么问你，阿粉是这么回答的。

(1) 减少内存开销

假设使用可重入锁，那么每个节点都需要继承AQS，但并不是每个节点都需要同步支持，只有链表的头节点(红黑树的根节点)需要同步，这无疑消耗巨大内存。

(2) 获得JVM的支持

可重入锁毕竟是API级别的，后续的性能优化空间很小。synchronized则是JVM直接支持的，JVM能够在运行时作出相应的优化措施：锁粗化、锁消除、锁自旋等等。使得synchronized能够随着JDK版本的升级而不改动代码的前提下获得性能上的提升。

也是亏了阿粉在面试之前的时候看过很多这样的文章，很多东西都专门去比对了一下，于是第二个问题结束了。

面试题3：你们是怎么避免 SQL 注入的?
 

面试题1：HashMap和ConcurrentHashMap的区别

我们都知道HashMap是线程不安全的，当我们在有并发的情况下去使用HashMap的put，还有get等一些方法的时候，CPU直接飙升，而且也没有办法保证线程的安全性，但是更加安全的HashTable呢?

因为在HashTable里面put和get的方法的，没一个都是加上了synchronize，虽然保证了线程的安全性，但是效率就比较低下了，在我们进行并发访问的时候，每次只能是一个线程进行操作，其他的线程就只能是阻塞执行，所以，他的效率相对来说，是非常低的，这时候我们就出现了ConcurrentHashMap。

而ConcurrentHashMap则使用了锁分段(减小锁范围)、CAS(乐观锁，减小上下文切换开销，无阻塞)等等技术，这时候你回答了，就出现了一环套一环的操作，那么你就分别来说说把。

在JDK1.7中，ConcurrentHashMap使用的锁分段技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。

在JDK1.8中，ConcurrentHashMap采用CAS和synchronized方式处理并发。以put操作为例，CAS方式确定key的数组下标，synchronized保证链表节点的同步效果

阿粉也没怎么墨迹，直接说能给我一张纸么?于是阿粉画了一个之前在网上看的图。

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!