当前位置:网站首页>2020最新B站面试经历,含答案!

2020最新B站面试经历,含答案!

2020-12-06 16:01:48 程序猿欧文

B站面试经历,附带答案!

1 操作系统相关

自旋锁和一般锁的区别是什么?为什么要使用自旋锁?
当一个线程在获取锁的时候,如果这个锁已经被其他线程获取,那么这个线程不会破门而入,而是循环等待,但是嗷嗷待哺,需要不断地嗷嗷叫判断锁是否被成功获取,直到获取到锁才会退出循环。

自旋锁通常会出现哪些问题?
如果某个线程拿着锁死不放手,其他线程没法拿到这把锁,只好等待获取锁的线程进入循环等待的状态,等待不是睡觉,还是会消耗CPU,等待久了就会导致CPU的使用率太高。

那么自旋锁和其他锁到底有啥不同?
从线程状态来看,自旋锁的状态是运行-运行-运行。而非自旋锁的状态是运行---阻塞---运行,所以自旋锁会更高效。

不管是什么锁,都是为了实现保护共享资源而提出的一种锁机制,都是为了对某项资源的互斥使用。对于互斥锁而言,如果资源已经被占用,那么资源的申请者只会进入睡眠的状态。而自旋锁不会引起调用者睡眠,而是一直循环在那里查看该自旋锁的保持着是否已经释放了锁。

那么在Java中如何去实现一个自旋锁
public class SpinLock {
private AtomicReference cas = new AtomicReference();
public void lock() {
Thread current = Thread.currentThread();
// 利用CAS
while (!cas.compareAndSet(null, current)) {
// DO
}
}
public void unlock() {
Thread current = Thread.currentThread();
cas.compareAndSet(current, null);
}
}
上段代码中,方法lock利用的CAS,当线程A获取锁的时候,成功获取不会进入while循环。如果此时线程A没有释放锁,当线程B来获取锁的时候,由于不满足CAS,就会进入whilei循环,不断判断是否满足CAS,直到线程A调用unlock释放。

自旋锁有哪些优点?
因为运行在用户态,没有上下文的线程状态切换,线程一直处于active,减少了不必要的上下文切换,从而执行速度较快
因为非自旋锁在没有获取锁的情况下会进入阻塞状态,从而进入内核态,此时就需要线程的上下文切换,因为阻塞后进入内核调度状态,会导致用户态和内核态之间的切换,影响锁的性能。
了解哪些I/O模型?select是阻塞IO吗?
首先将IO模型给安排一遍,然后把自己很熟悉的IO模型详细说一波并介绍出应用场景,这个装的X就算比较完美,具体的非常详细的在下一篇文章,这里简要说一波。这一部分在上一篇详细阐述过
阻塞IO

我们知道在调用某个函数的时候无非就是两种情况,要么马上返回,然后根据返回值进行接下来的业务处理。当在使用阻塞IO的时候,应用程序会被无情的挂起,等待内核完成操作,因为此时的内核可能将CPU时间切换到了其他需要的进程中,在我们的应用程序看来感觉被卡主(阻塞)了。

非阻塞IO

当使用非阻塞函数的时候,和阻塞IO类比,内核会立即返回,返回后获得足够的CPU时间继续做其他的事情。

IO复用模型

当使用fgets等待标准输入的时候,如果此时套接字有数据但不能读出。IO多路复用意味着可以将标准输入、套接字等都当做IO的一路,任何一路IO有事件发生,都将通知相应的应用程序去处理相应的IO事件,在我们看来就反复同时可以处理多个事情。这就是IO复用。

信号驱动IO

在信号驱动式 I/O 模型中,应用程序使用套接口进行信号驱动 I/O,并安装一个信号处理函数,进程继续运行并不阻塞。当数据准备好时,进程会收到一个 SIGIO 信号,可以在信号处理函数中调用 I/O 操作函数处理数据。

异步IO

用程序告知内核启动某个操作,并让内核在整个操作(包括将数据从内核拷贝到应用程序的缓冲区)完成后通知应用程序。那么和信号驱动有啥不一样?

讲讲select和epoll的区别?
这里一样的套路,先说出两者的用途,然后两者的优缺点。
select的缺点

select返回的是含有整个句柄的数组,应用程序需要遍历整个数组才能发现哪些句柄发生了事件
select的触发方式是水平触发,应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作,那么之后每次select调用还是会将这些文件描述符通知进程
内核 / 用户空间内存拷贝问题,select每次都会改变内核中的句柄数据结构集,因而每次select调用时都需要从用户空间向内核空间复制所有的句柄数据结构,产生巨大的开销
单个进程能够监视的文件描述符的数量存在最大限制,通常是1024,当然可以更改数量
epoll实现

epoll在内核中会维护一个红黑树和一个双向链表,红黑树存放通过epoll_ctl方法向epoll对象中添加进来的事件,所以不需要每次调用epoll_wait都全量复制所有的事件结构。双向链表存放就绪的事件,所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系,也就是说,当相应的事件发生时会调用这个回调方法,这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。调用epoll_wait就会直接返回链表中的就绪事件,效率高。
select适合少量活跃连接,一般几千。

epoll适合大量不太活跃的连接。

乐观锁和悲观锁了解吗?

这个问题延伸的问题会很多,比如线程安全,CAS原理,优缺点等。
啥是悲观和乐观,咋们面试的时候不得乐观一些。想给面试来一波官方解释,然后大白话解释一波就差不多了。

官方:悲观锁是总是假设最坏的情况,每次那数据都认为别人会修改它,所以每次去那数据都要上锁,这样别人去拿这个数据就会阻塞。乐观锁就不一样了,总是觉得一切都是最好的安排,每次拿数据都认为别人不会修改,所以也就不上锁,但是在更新的时候会判断这个期间别人有没有更新这个数据。

什么是缓存穿透?如何避免?什么是缓存雪崩?何如避免?
缓存穿透

一般来说,缓存系统会通过key去缓存查询,如果不存在对应的value,就应该去后端系统查找(比如DB)。这个时候如果一些恶意的请求到来,就会故意查询不存在的key,当某一时刻的请求量很大,就会对后端系统造成很大的压力。这就叫做缓存穿透。
如何避免?

对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该key对应的数据insert了之后清理缓存。对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中,查询时通过该bitmap过滤。
缓存雪崩

当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,会给后端系统带来很大压力。导致系统崩溃。
如何避免?

在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。
做二级缓存,A1为原始缓存,A2为拷贝缓存,A1失效时,可以访问A2,A1缓存失效时间设置为短期,A2设置为长期。

不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀。

2 redis相关

如果是后端/服务端面试的同学,怎么说都的去找一本redis书来看看,其出现的概率只有那么大了,切记切记。看看B站问了哪几个问题。
redis的淘汰删除策略了解吗?
能说不了解吗,就算是没有听说过,咋们也可以来一句:“不好意思面试官,这一块还不怎么深入,但是从字面意思来理解巴拉巴拉”,不至于一脸懵逼。下面我们看看redis的缓存策略

Redis中通过maxmemory参数来设定内存的使用上限,如果Redis所使用内存超过设定的最大值,那么会根据配置文件中的策略选取要删除的key来删除,从而留出新的键值空间。主要的六种淘汰key策略

volatile-lru
在键空间中设置过期时间,移除哪些最近最少使用的key,占着茅坑不拉屎的key
allkeys-lru
移除最近最少使用的key
volatile-random
在键空间中设置过期时间,随机移除一个key
allkeys-random
随机移除一个key
noeviction
当内存使用达到阀值的时候,所有引起.........

版权声明
本文为[程序猿欧文]所创,转载请带上原文链接,感谢
https://my.oschina.net/mikeowen/blog/4776989