1. 面经总结

1.1. hashmap的底层数据结构,put的过程。

JDK1.7 ,HashMap底层是数据和链表结合在一起使用,也就是链表散列

JDK1.8 ,HashMap底层是数据和链表和红黑树结合一起使用

jdk1.8在解决哈希冲突时有了较大的变化,当链表长度大于阈值(默认为8)时,将链表转化为红黑树,以减少搜索时间。

put过程

1.2. Hashmap是否是线程安全的,多线程下会有什么问题?concurrentHashMap底层是如何实现线程安全的。

HashMap不是线程安全的,HashTable 和concurrentHashMap是线程安全的,HashTable 是全局锁,HashTable容器使用synchronized来保证线程安全,concurrentHashMap分段锁,性能更高。

HashMap在多线程下会出现死循环问题

原因:HashMap出现死循环的条件是,当两个线程同时对原有的旧的Hash表扩容时,当其中一个线程正在扩容时(遍历单向链表)切换到另外一个线程进行扩容操作,并且在线程二中完成了所有的扩容操作,此时再切换到线程1中就可能造成单向链表形成一个环,从而在下一次查询操作时就可能发生死循环。

concurrentHashMap底层是如何实现线程安全的?

ConcurrentHashMap采用的是分段式锁,可以理解为把一个大的Map拆封成N个小的Segment,在put数据时会根据hash来确定具体存放在哪个Segment中,Segment内部的同步机制是基于ReentryLock操作的,每一个Segment都会分配一把锁,当线程占用锁访问其中一段数据时,其他段的数据也能被其他线程访问,也就是实现并发访问。

能说一下ConcurrentHashMap在JDK1.7和JDK1.8中的区别吗?

  • JDK1.8的实现降低锁的粒度,JDK1.7版本锁的粒度是基于Segment的,包含多个HashEntry,而JDK1.8锁的粒度就是HashEntry(首节点)
  • JDK1.8版本的数据结构变得更加简单,使得操作也更加清晰流畅,因为已经使用synchronized来进行同步,所以不需要分段锁的概念,也就不需要Segment这种数据结构了,由于粒度的降低,实现的复杂度也增加了
  • JDK1.8使用红黑树来优化链表,基于长度很长的链表的遍历是一个很漫长的过程,而红黑树的遍历效率是很快的,代替一定阈值的链表,这样形成一个最佳拍档

1.3. synchronized实现原理与锁的升级过程。

锁的升级过程

升级过程简单理解为: 偏向锁 -> 轻量级锁 -> 重量级锁

synchronized实现原理

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令,其中 monitorenter 指令指向同步代码块的开始位置,monitorexit 指令则指明同步代码块的结束位置。

synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令,取得代之的确实是 ACC_SYNCHRONIZED 标识,该标识指明了该方法是一个同步方法。 不过两者的本质都是对对象监视器 monitor 的获取。

在执行monitorenter时,会尝试获取对象的锁,如果锁的计数器为 0 则表示锁可以被获取,获取后将锁计数器设为 1 也就是加 1。

在执行 monitorexit 指令后,将锁计数器设为 0,表明锁被释放。如果获取对象锁失败,那当前线程就要阻塞等待,直到锁被另外一个线程释放为止。

1.4. 数据库是否用了索引?用explain无法看出索引用了哪一部分?

遇到非等值判断时匹配停止

a = ? and b = ? and c= ?
a = ? and b = ? and c > ?
a = ? and b > ? and c > ?, 只用到索引的一部分(a,b),因为b把数据阻断了,b不是定植时,c时无序的,无法使用(a,b,c)索引

1.5. spring循环引用的问题,A->B->A问题,怎么解决

Spring 为了解决单例的循环依赖问题,使用了三级缓存。其中一级缓存为单例池(singletonObjects),二级缓存为提前曝光对象(earlySingletonObjects),三级缓存为提前曝光对象工厂(singletonFactories)。

假设A、B循环引用,实例化 A 的时候就将其放入三级缓存中,接着填充属性的时候,发现依赖了 B,同样的流程也是实例化后放入三级缓存,接着去填充属性时又发现自己依赖 A,这时候从缓存中查找到早期暴露的 A,没有 AOP 代理的话,直接将 A 的原始对象注入 B,完成 B 的初始化后,进行属性填充和初始化,这时候 B 完成后,就去完成剩下的 A 的步骤,如果有 AOP 代理,就进行 AOP 处理获取代理后的对象 A,注入 B,走剩下的流程。

1.6. 举个不用回表的例子

回表:数据库根据索引找到了指定的记录所在行后,还需要根据rowid再次到数据块里取数据的操作。 比如:select code from order where mcode = ‘M001’;因为mcode索引,所以查询mcode的索引,查到符合要求的数据的rowid(索引内是不会保存具体数据的),再根据rowid,查询到具体的数据,拿到code。

如何避免回表

使用覆盖索引。

使用mcode的索引,使用(mcode,code)的联合索引。 在查找到mcode的索引后,可以直接拿到code了,不需要再回表。

1.7. Mysql主键用uuid会有什么问题?

主键一般使用 mysql的自增主键、uuid、雪花算法。

自增主键:减少了页分裂和碎片的产生 效率最高

uuid: uuid毫无规律、新增的值不一定比之前的主键值大,所以innodb无法总数将新行插入到索引的最后

  • ① 写入的目标页很可能已经刷新到磁盘上并且从缓存上移除,或者还没有被加载到缓存中,innodb在插入之前不得不先找到并从磁盘读取目标页到内存中,这将导致大量的随机IO
  • ②因为写入是乱序的,innodb不得不频繁的做页分裂操作,以便为新的行分配空间,页分裂导致移动大量的数据,一次插入最少需要修改三个页以上
  • ③由于频繁的页分裂,页会变得稀疏并被不规则的填充,最终会导致数据会有碎片

1.8. 聚蔟索引和非聚蔟索引的区别,是否分别对应主键索引、辅助索引? 是的

聚簇索引:将数据存储与索引放到了一块,索引结构的叶子节点保存了行数据.

非聚簇索引:将数据与索引分开存储,索引结构的叶子节点指向了数据对应的位置.

1.9. jvm垃圾回收是如何做的?

  • 标记清除算法 ,产生内存碎片
  • 标记整理算法 ,GC暂停时间会加长
  • 复制算法, 内存空间使用率只有50%,可分配内存减少了一半
  • 分代收集算法,分为eden和survivor区, Survivor 由 FromSpace与ToSpace组成,新生代复制算法来完成收集,老年代使用用“标记-清除”算法或“标记-整理”算法来进行回收。

特别地,在分代收集算法中,对象的存储具有以下特点: 对象优先在 Eden 区分配。 大对象直接进入老年代。 长期存活的对象将进入老年代,默认为 15 岁。

1.10. jvm运行时有哪些数据区

  • 程序计数器:记录程序执行的位置,有了程序计数器,就可以保证在涉及线程上下文切换的情景下,程序依然能够正确无误地运行下去。
  • Java虚拟机栈:存着程序运行时的局部变量,主要包含局部变量表、操作数栈。
  • 本地方法栈:为native方法服务
  • 方法区:线程共享,用于存储类的元信息、静态变量、常量、全局变量、普通方法的字节码等内容。
  • 堆:线程共享、存储实例对象和数组

1.11. java垃圾回收器有哪些

  • Serial(串行GC)收集器 ...
  • ParNew(并行GC)收集器 ...
  • Parallel Scavenge(并行回收GC)收集器 ...
  • Serial Old(串行GC)收集器 ...
  • Parallel Old(并行GC)收集器 ...
  • CMS(并发GC)收集器 ...
  • G1收集器

1.12. 哈希冲突如何解决

  • 开放寻址法,冲突则根据指定步长向后寻找直到找到空位或没有位置。
  • 再哈希发,有多个不同的Hash函数,当发生冲突时,使用第二个,第三个,等哈希函数 直到不再冲突。
  • 建立公共溢出区, 将哈希表分为基本表和溢出表两部分,凡是和基本表发生冲突的元素,一律填入溢出表 ,缺点: 如未能命中哈希表 需要遍历查找溢出表 查询效率低。
  • 拉链法 ,如出现冲突,将其作为链表一个节点加入头或者尾巴处。

1.13. b+树叶子节点存的是指针吗?存的是数据

© gaohueric all right reserved,powered by Gitbook文件修订时间: 2021-12-08 23:22:22

results matching ""

    No results matching ""