文章目录
- 进程间通信方式
- 栈上分配内存快还是堆上,为什么?
- channel 底层
- 七层模型
- tcp、udp
- redis持久化的方式以及使用场景
- 如何实现线程池?
- 算法:二叉树俯视图
- 二面
- 怎么判断给定ip是否在给定ip区间内?
- 如何优化慢SQL?
- 什么情况不建议使用索引
- 线程池的几种拒绝策略及其应用场景
- http与tcp区别
- 长连接与短连接
- 讲讲tcp的挥手?
- time wait,过多怎么办
- 算法:忘了...
- 三面
写在前面
滴滴面试感觉还行吧,挺注重基础的,很多时间都花在了挖项目上面,所以大家一定要很熟悉自己的项目!面试官水平也很高。不过也感叹这个曾经的大厂现在变成这个样子,唉。。
笔试
略
一面
进程间通信方式
管道、消息队列、信号量、共享内存
栈上分配内存快还是堆上,为什么?
显然从栈上分配内存更快,因为从栈上分配内存仅仅就是栈指针的移动而已
- 操作系统会在底层对栈提供支持,会分配专门的
寄存器存放栈的地址
。 - 栈的入栈出栈操作也十分简单,并且有
专门的指令执行
,所以栈的效率比较高也比较快。 - 堆的生长空间向上,地址越来越大,栈的生长空间向下,地址越来越小。
channel 底层
七层模型
从上而下分别是 应用层,表示层,会话层,传输层,网络层,数据链路层,物理层等等…
tcp、udp
TCP 是可靠传输,面向连接,基于流,占用资源多,效率低。
UDP是尽最大努力交付,基于无连接,基于报文,UDP 占用系统资源较少,效率高。
redis持久化的方式以及使用场景
Redis提供 RDB 和 AOF 两种持久化机制 , 有了持久化机制
我们基本上就可以避免进程异常退出时所造成的数据丢失的问题了,Redis能在下一次重启的时候利用之间产生的持久化文件实现数据恢复
。
- RDB持久化就是指的讲
当前进程的数据生成快照存入到磁盘
中,触发RDB机制又分为手动触发与自动触发
。 -
AOF 持久化
是以独立的日志记录每次写命令,重启 Redis 的时候再重新执行AOF文件中命令以达到恢复数据,所以AOF主要就是解决持久化的实时性
。
如何实现线程池?
线程池有两部分组成:同步队列和线程池。
- 同步队列:以链表的形式创建一个
同步队列
,同步队列的主要工作就是通过Put()
函数向队列里面添加事务,通过Get()函数从队列里面取出事务。 - 线程池:主要由线程组(注:线程组里面存放的时
thread 类型
的共享只能指针,指向工作的线程)构成,通过Start()
函数向线程组中添加numThreads
个线程,并使得每一个线程调用RunThread()
函数来获取同步队列的事务并执行事务;通过Stop()
函数停止线程池的工作。
算法:二叉树俯视图
二面
怎么判断给定ip是否在给定ip区间内?
IP地址可以转换成整数,可以将IP返回化整为整数范围进行排查。
如何优化慢SQL?
- 查看是否使用到了索引。
- 查看 SQL语句 是否符合最左匹配原则。
- 对查询进行优化,尽可能避免全表扫描
- 字段冗余,减少跨库查询或多表连接操作
- 将一些常用的数据结构放在缓冲中(部门名字,组织架构之类的),就不需要查数据库了。
什么情况不建议使用索引
- 在where条件中(包括group by以及order by)里用不到的字段不需要创建索引,索引的价值是快速定位,如果起不到定位的字段通常是不需要创建索引的。
- 数据量小的表最好不要使用索引,少于1000个
- 字段中如果有大量重复数据(性别),也不用创建索引
- 避免对经常更新的表创建过多的索引。
- 不建议使用无序的值作为索引。
线程池的几种拒绝策略及其应用场景
当时都不知道这是个啥…
具体看这篇博客吧 线程池拒绝策略应用场景
http与tcp区别
http 就是基于传输层的 tcp 实现的一个应用层协议。
长连接与短连接
长连接意味着进行一次数据传输后,不关闭连接,长期保持连通状态。
短连接意味着每一次的数据传输都需要建立一个新的连接,用完再马上关闭它。下次再用的时候重新建立一个新的连接,如此反复。
讲讲tcp的挥手?
数据传输完毕之后,通信的双方都可释放连接。现在A和B都处于ESTABLISHED
状态。
- A的应用进程先向TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接。A把链接释放报文段首部的终止控制位
FIN
置为1
,其序号为seq=u
,它等于前面以传送过的数据的最后一个字节的序号加1
.这时候A进入了FIN-WAIT-1(终止等待1)
状态,等待B的确认。
注意:TCP规定,FIN报文段即使不携带数据,他也消耗掉一个序号!!
- B 收到链接释放报文段后即发出确认,确认号是
ack = u + 1
,而这个报文段自己的序号是v
,等于B前面已传送过的数据的最后一个字节的序号加1
.然后B就进入CLOSE-WAIT(关闭等待)
状态。TCP服务器进程这时应通知高层应用进程,因而从A到B这个方向的链接就释放了,这时的TCP链接处于半关闭状态,即A已经没有数据要发送了,但B若发送数据,A仍要接收,也就是说,从B到A这个方向的连接并未关闭。这个状态可能要维持一段时间。 - A收到来自B的确认后,就进入了
FIN-WAIT-2(终止等待2)
状态满等待B发出的连接释放报文段。若B已经没有要向A发送的数据,其应用进程就通知TCP释放连接,这时B发出的连接释放报文段必须使FIN = 1
,现假定B的序号为w
(在半关闭状态B可能又发送了一些数据)。B还必须重复上次已发送过的确认号ack = u + 1
.这时B就进入LAST-ACK(最后确认)
状态,等待A的确认。 - A在收到了B的链接释放报文段后,必须对此发出确认。在确认报文段中把
ACK置1
,确认号ack=w+1
,而自己的序号是seq=u+1
(根据TCP标准,前面发送过的FIN报文段要消耗一个序号)。然后进入到TIME-WAIT
(时间等待)状态。注意:现在TCP连接还没有还没有释放掉
。必须经过时间等待计时器设置的时间2MSL
后,A才能进入CLOSED状态。
时间MSL叫做最长报文段寿命,RFC793建议设在两分钟。但是在现在工程来看两分钟太长了,所以TCP允许不同的实现可以根据具体情况使用更小的MSL值。
time wait,过多怎么办
- 修改TIME_WAIT连接状态的上限值
- 启动快速回收机制
- 开启复用机制
- 修改短连接为长连接方式
- 由客户端来主动断开连接
算法:忘了…
三面
聊人生…