面试题13

最新推荐文章于 2023-02-08 16:43:58 发布

Tuzki_小辣鸡

最新推荐文章于 2023-02-08 16:43:58 发布

阅读量212

点赞数

分类专栏：校招面试题文章标签： Java面试题校招面试题

本文链接：https://blog.csdn.net/weixin_37659242/article/details/90247932

版权

校招面试题专栏收录该内容

12 篇文章 0 订阅

订阅专栏

object有哪些方法

hashCode()

返回对象的哈希码值。hashCode()相等equals()不一定true

finalize()

当垃圾收集确定不再有对该对象的引用时，垃圾收集器在对象上调用该对象。一个子类覆盖了处理系统资源或执行其他清理的finalize方法。

clone()

创建并返回此对象的副本

HashMap便利方式(推荐使用entrySet())

第一种:

效率高

Map map = new HashMap(); 
Iterator iter = map.entrySet().iterator(); 
while (iter.hasNext()) { 
    Map.Entry entry = (Map.Entry) iter.next(); 
    Object key = entry.getKey(); 
    Object val = entry.getValue(); 
}

第二种:

效率低

Map map = new HashMap(); 
Iterator iter = map.keySet().iterator(); 
while (iter.hasNext()) { 
    Object key = iter.next(); 
    Object val = map.get(key); 
}

如何打破双亲委派模型

1：自己写一个类加载器

2：重写loadclass方法

3：重写findclass方法

这里最主要的是重写loadclass方法，因为双亲委派机制的实现都是通过这个方法实现的，先找附加在其进行加载，如果父加载器无法加载再由自己来进行加载，源码里会直接找到根加载器，重写了这个方法以后就能自己定义加载的方式了

Thread.sleep(0)作用

Thread.Sleep(0) 并非是真的要线程挂起0毫秒，意义在于这次调用Thread.Sleep(0)的当前线程确实的被冻结了一下，让其他线程有机会优先执行。Thread.Sleep(0) 是你的线程暂时放弃cpu，也就是释放一些未用的时间片给其他线程或进程使用，就相当于一个让位动作。

负载因子为什么是0.75

其中loadFactor加载因子是表示Hsah表中元素的填满的程度.

若:加载因子越大,填满的元素越多,好处是,空间利用率高了,但:冲突的机会加大了.链表长度会越来越长,查找效率降低。

反之,加载因子越小,填满的元素越少,好处是:冲突的机会减小了,但:空间浪费多了.表中的数据将过于稀疏（很多空间还没用，就开始扩容了）

冲突的机会越大,则查找的成本越高.

因此,必须在 "冲突的机会"与"空间利用率"之间寻找一种平衡与折衷. 这种平衡与折衷本质上是数据结构中有名的"时-空"矛盾的平衡与折衷.

如果机器内存足够，并且想要提高查询速度的话可以将加载因子设置小一点；相反如果机器内存紧张，并且对查询速度没有什么要求的话可以将加载因子设置大一点。不过一般我们都不用去设置它，让它取默认值0.75就好了。

为什么数据库索引结构用B+树而不用红黑树

由于 B+ 树分支比二叉树更多，所以相同数量的内容，B+ 树的深度更浅，深度代表什么？代表磁盘 io 次数，数据库设计的时候 B+ 树有多少个分支都是按照磁盘一个簇上最多能放多少节点设计的。

JDK1.8的HashMap不一定达到阀值才触发reSize()？

一种是元素达到阀值了，一种是HashMap准备树形化(红黑树)但又发现数组太短（长度小于64），这两种情况均可能发生扩容。

JDK1.8使用红黑树这种数据结构来解决链表过长的问题（可以简单理解为用红黑树遍历比链表遍历速度快，时间复杂度低），默认链表长度达到8就将链表树形化（变为红黑树）

那为什么树形化的时候可能会发生扩容呢？

想想刚刚的例子数组长度为1，所有元素全部在数组的第0个位置形成一条链表，这例子是一种极端情况，数组长度过小，那自然就会经常发生hash碰撞，那形成长链表是肯定的，这个时候树形化其实是治标不治本，因为引起链表过长的根本原因是数组过短，所以在JDK1.8源码中，执行树形化之前，会先检查数组长度，如果长度小于64，则对数组进行扩容，而不是进行树形化。

equals和hashcode为什么要一起重写

如果我们对一个对象重写了euqals，意思是只要对象的成员变量值都相等那么euqals就等于true，但不重写hashcode，那么我们再new一个新的对象，当原对象.equals（新对象）等于true时，两者的hashcode却是不一样的，由此将产生了理解的不一致，如在存储散列集合时（如Set类），将会存储了两个值一样的对象，导致混淆，因此，就也需要重写hashcode()

==和equals()区别

基本数据类型==比较的是内容

包装类 == 比较的是它们内存地址

包装类 equals()，(String Integer date) 等因为重写了equals()比较的是内容

没有重写equals()的，实用的还是object的equals()，比较的是内存地址(StringBuffer、StringBuilder)

秒杀

秒杀设计思路：

前端：页面静态化，禁止重复提交。

页面静态化：将前端可以静态的资源静态化。
禁止重复提交：秒杀开始之后，可以对用户点击后响应前按钮置灰。

后端：可拓展，缓存，限流，削峰，异步处理

可拓展：服务的可扩展，可以水平添加机器将用户请求分担到不同的机器上去。数据库可扩展，支持分库分表，对于用户的请求，映射到不同的数据库，减少单台数据库的压力。

内存缓存：参加秒杀系统的商品是事先可知的，可以将参加秒杀的商品信息事先缓存到redis等缓存系统中，这样可以大大的提高系统的吞吐量，减少关系型数据库的读写压力。

限流：一单秒杀开始，实际秒杀成功的用户只是库存的数量，在库存没有之后，将前端的秒杀入口关闭。

削峰：数据库削峰。对于秒杀系统瞬时会有大量用户涌入，所以在抢购一开始会有很高的瞬间峰值。对于关系型数据库而言，这个是致命的，是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。

异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。

案例：利用redis+mysql实现简单的秒杀系统

Redis是一个分布式key-value缓存系统，value支持多种数据结构，这里value可以选择两种类型，String（或者hash）：主要用于记录商品的库存，对商品减库存。Set集合（这里不要用list集合，list集合是可重复的，set是不可重复的，可以保证一个用户只卖一次，如果一个用户可以买多次那么可以使用list集合）：用于存储用户的id获取其他唯一确定一个用户的值。

在秒杀开始的前：可以使用批处理，将参加秒杀的产品信息缓存到redis中。这里将产品的业务唯一字段作为key，库存作为value。这里的key要和前端缓存的key一致。

在秒杀开始时：：用户大量提交。根据用户提交的产品信息，获取到redis中需要的key值，查询缓存（为了保证缓存有效，如果第一次没有查询到，可以到数据库查询，然后在缓存一下，不过一般不会出现），得到库存量，判断当前库存是否大于零，如果大于零，判断当前的set集合中是否用该用户ID，如果没有，减库存并且将用户的ID放入集合中，并对库存减一，如果库存为0，提示用户，商品已售完等文案信息，如果集合中已经存在该用户id，则不做任何处理，直接处理下一个请求。直到最后库存售完，上面的过程可以利用redis事务和watch功能完成对数据一致性的控制即超卖问题。
库存售完后：程序开始启动一个有个后台线程，可以阻塞等待商品库存售完的通知，在上面一步，库存一旦售完，后台进程获取set集合中的用户信息，异步处理需要操作的购买等后续操作。