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，设置不同的过期时间，让缓存失效的时间点尽量均匀。
操作系统复习资料
========
给大家分享一份阿里P8Java大牛呕心沥血整理的《程序员必知的操作系统》PDF文档学习资料
先来看下这份资料的目录
内容涉及
-
认识操作系统
-
进程和线程
-
内存管理
-
文件管理
-
I/O
-
死锁
-
操作系统面试题
-
操作系统核心概念
字是一个一个敲的，图是一笔一笔画的。
可以看到图非常清晰，而且排版样式非常好
还为你汇总了操作系统面试题
还有所有操作系统名词汇总
这份PDF 一共是 306 页，17w 字，我想这应该是全网第一份操作系统知识的 PDF 了吧，希望大家能够珍藏。
转发+关注，然后添加VX（tkzl6666）即可获得《程序员必知的操作系统》PDF文档学习资料的免费领取方式。
redis相关
=======
如果是后端/服务端面试的同学，怎么说都得去找一本redis书来看看，其出现的概率只有那么大了，切记切记。看看B站问了哪几个问题。
- redis的淘汰删除策略了解吗？
能说不了解吗，就算是没有听说过，咱们也可以来一句：“不好意思面试官，这一块还不怎么深入，但是从字面意思来理解巴拉巴拉”，不至于一脸懵逼。下面我们看看redis的缓存策略
Redis中通过maxmemory参数来设定内存的使用上限，如果Redis所使用内存超过设定的最大值，那么会根据配置文件中的策略选取要删除的key来删除，从而留出新的键值空间。主要的六种淘汰key策略：
- volatile-lru
在键空间中设置过期时间，移除那些最近最少使用的key，占着茅坑不拉屎的key
- allkeys-lru
移除最近最少使用的key
- volatile-random
在键空间中设置过期时间，随机移除一个key
- allkeys-random
随机移除一个key
- noeviction
当内存使用达到阀值的时候，所有引起申请内存的命令会报错；
ok，现在知道了需要淘汰哪些key，那我们如何去淘汰这些key？
- 定时删除
很简单，设置一个闹钟，闹钟响了就删除即可。这种方式对于内存来说还是比较友好，内存不需要啥额外的操作，直接通过定时器就可保证尽快的删除。对于CPU来说就有点麻烦了，如果过期键比较多，那么定时器也就多，这删除操作就会占用太多的CPU资源。
- 惰性删除
每次从键空间获取键的时候检查键的过期时间，如果过期了，删除完事。
- 定期删除
每隔一段时间就去数据库检查，删除过期的键。
这种方案是定时删除和惰性删除的中和方法，既通过限制删除操作执行的时长来减少对CPU时间的影响，也能减少内存的浪费。但是难点在于间隔时长需要根据业务情况而定。
redis复习资料
=========
一位有着十年经验的互联网分布式高并发技术老兵，梳理自己多年 Redis 实践经验，写了这本书《Redis深度历险：核心原理与应用实战》，以帮助更多工程师更快，更深入的了解 Redis 。
书籍内容分为五大部分：
===========
**一、Redis应用：**分布式锁、延时队列、位图、HyperLogLog、布隆过滤器、限流、GeoHash、Scan
**二、Redis原理：**IO现场模型、通信协议、持久化、管道、事务、PubSub、对象压缩、主从同步
**三、Redis集群：**Sentinel、Codis、Cluster
**四、Reids拓展知识：**Stream、Info命令、分布式锁、过期策略、LRU、懒删除、Jedis
**五、Redis源码剖析：**字符串、字典、压缩列表、快速列表、跳跃列表、紧凑列表、基数树
全书图文并茂，通俗易懂，看看下面的动图感受一下：
转发+关注，然后然后添加VX（tkzl6666）即可获得《Redis深度历险》PDF文档学习资料的免费领取方式。
Mysql
=====
- Mysql中使用的锁有哪些？什么时候使用行锁，什么时候会使用表锁？
InnoDB中的行锁是通过索引上的索引项实现，主要特点是，只有通过索引条件检索数据，InnoDB才会使用行级锁，否则InnoDB将使用表锁。
这里注意，在Mysql中，行级锁不是锁记录而是锁索引。索引又分为主键索引和非主键索引两种。如果在一条语句中操作了非主键索引，Mysql会锁定该非主键索引，再锁定相关的主键索引。
-
了解过间隙锁吗？间隙锁的加锁范围是怎么确定的？
-
了解B+树吗？B+树什么时候会出现节点分裂？
这个回答在上一篇的B+树已经详细说了。这里简述一下：
-
将已满节点进行分裂，将已满节点后M/2节点生成一个新节点，将新节点的第一个元素指向父节点。
-
父节点出现已满，将父节点继续分裂。
-
一直分裂，如果根节点已满，则需要分类根节点，此时树的高度增加。
-
事务还没执行完数据库挂了，重启的时候会发生什么？
-
undo日志和redo日志分别是干嘛的？
redo log重做日志是InnDB存储引擎层的，用来保证事务安全。在事务提交之前，每个修改操作都会记录变更后的数据，保存的是物理日志-数据，防止发生故障的时间点，有脏页未写入磁盘，在重启mysql的时候，根据redo log进行重做从而达到事务的持久性
undo log回滚日志保存了事务发生之前的数据的一个版本，可以用于回滚，同时也提供多版本并发控制下的读。
- 简单讲讲数据库的MVCC的实现原理？
细说太多了，几个大写字母代表啥，这几个大写字母又是如何关联起来完事。细问再深究
- mysql的binlog日志什么时候会使用？
首先应该知道binlog是一个二进制文件，记录所有增删改操作，节点之间的复制都会依靠binlog来完成。从底层原理来说，binlog有三个模式
- 模式1–row模式
每一行的数据被修改就会记录在日志中，然后在slave段对相同的数据进行修改。比如说"update xx where id in(1,2,3,4,5)"，使用此模式就会记录5条记录
- 模式2–statement模式
修改数据的sql会记录到master的binlog中。slave在复制的时候sql thread会解析成和原来maseter端执行过的相同的sql在此执行
- 模式3–mixed模式
mixed模式即混合模式，Mysql会根据执行的每一条具体sql区分对待记录的日志形式。那么binlog的主从同步流程到底是怎样的
流程简述：
Master执行完增删改操作后都会记录binlog日志,当需要同步的时候会主动通知slave节点，slave收到通知后使用IO THREAD主动去master读取binlog写入relay日志(中转日志),然后使 SQL THREAD完成对relay日志的解析然后入库操作,完成同步。
mysql复习资料
扫一扫
12万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
