共计 2758 个字符,预计需要花费 7 分钟才能阅读完成。
本期是【大厂面试 】系列文章的第4 期,题目出自美团到店二面。
面试现场
面试官 : 首先你来讲讲过程和线程有什么区别?
独白:老八股文了哈哈
大彬:过程是零碎进行资源分配和调度的独立单位,每一个过程都有本人的内存空间和系统资源
大彬:线程是过程的一个实体,是 CPU 调度和分派的根本单位,它是比过程更小的能独立运行的根本单位
大彬:多线程是实现并发机制的一个无效伎俩。过程和线程一样都是实现并发的根本单位
面试官 : 那为什么要用多线程呢?
独白:嘿嘿,这个简略
大彬:应用多线程最次要的起因是进步零碎的资源利用率。
大彬:多个线程同时运行,能够缩小线程上下文切换的开销,进步并发的能力和 CPU 的利用效率。
大彬:在平时工作中多线程也是常见的。比方 Tomcat 每解决一个申请都会从线程连接池里取一个线程去解决。
面试官 : 嗯,平时在应用多线程的时候,可能会遇到线程平安的问题吧。讲讲什么是线程平安?
大彬:我是这么了解的,当多个线程拜访一个对象时,如果不必思考这些线程在运行时环境下的调度和交替执行,也不须要进行额定的同步,调用这个对象的行为都能够取得正确的后果,那这个对象就是线程平安的。
面试官 : 那你平时怎么解决线程平安问题的?
大彬:这个还得具体问题具体分析。首先判断有没有线程平安问题,若有则依据具体的状况去解决线程平安的问题。
大彬 :比方波及到操作的原子性,能够思考应用atomic
包下的原子类。
大彬 :如果波及到对线程的管制,能够思考线程工具类CountDownLatch
/Semaphore
等等。
大彬 :汇合类的话,思考java.util.concurrent
包下的汇合类。
大彬 :还有synchronized
和lock
包下的类,redis 分布式锁等。
面试官 : 嗯哼,刚提到 Redis 分布式锁,你感觉什么场景下须要应用分布式锁呢?
大彬:在单机环境下,线程平安问题能够通过ReentrantLock
、synchronized
以及 concurrent
并发包下一些线程平安的类等来防止。
大彬:而在多机部署环境,须要在多过程下保障线程的安全性,Java 提供的这些 API 仅能保障在单个 JVM 过程内对多线程访问共享资源的线程平安,曾经不满足需要了。这时候就须要应用分布式锁来保障线程平安。
大彬 :Redis 2.6.12 之前的版本中采纳 setnx + expire
形式实现分布式锁。在 Redis 2.6.12 版本后 setnx
减少了过期工夫参数,只须要应用setnx
就能够实现分布式锁了。
面试官 : 那再讲讲 Redis 分布式锁的原理?
独白:面试造火箭,入职拧螺丝?
大彬:首先介绍下 Redis 的加锁逻辑。
大彬 :setnx
争抢 key 的锁,如果已有 key 存在,则不作操作,过段时间持续重试,保障只有一个客户端能持有锁。
大彬 :value 设置为 requestId
(能够应用机器 ip 拼接以后线程名称),示意这把锁是哪个申请加的,在解锁的时候须要判断以后申请是否持有锁,避免误会锁。比方客户端 A 加锁,在执行解锁之前,锁过期了,此时客户端 B 尝试加锁胜利,而后客户端 A 再执行del()
办法,则将客户端 B 的锁给解除了。
大彬 :再用expire
给锁加一个过期工夫,避免异样导致锁没有开释。
大彬:而后是解锁逻辑。
大彬 :首先获取锁对应的 value 值,查看是否与requestId
相等,如果相等则删除锁。应用 lua 脚本实现原子操作,保障线程平安。
面试官 : 不错,看你简历上写了相熟 TCP,来介绍下 TCP 四次挥手?
独白:嗯,这个嘛,很相熟
大彬:假如 A 是 client 端,B 是 server 端。
- 首先 A 的利用过程先向其 TCP 收回连贯开释报文段(
FIN=1,seq=u
),并进行再发送数据,被动敞开 TCP 连贯,进入FIN-WAIT-1
(终止期待 1)状态,期待 B 的确认。 - B 收到连贯开释报文段后即收回确认报文段(
ACK=1,ack=u+1,seq=v
),B 进入CLOSE-WAIT
(敞开期待)状态,此时的 TCP 处于半敞开状态,A 到 B 的连贯开释。 - A 收到 B 的确认后,进入
FIN-WAIT-2
(终止期待 2)状态,期待 B 收回的连贯开释报文段。 - B 发送完数据,就会收回连贯开释报文段(
FIN=1,ACK=1,seq=w,ack=u+1
),B 进入LAST-ACK
(最初确认)状态,期待 A 的确认。 - A 收到 B 的连贯开释报文段后,对此收回确认报文段(
ACK=1,seq=u+1,ack=w+1
),A 进入TIME-WAIT
(工夫期待)状态。此时 TCP 未开释掉,须要通过工夫期待计时器设置的工夫2MSL
(最大报文段生存工夫)后,A 才进入CLOSED
状态。B 收到 A 收回的确认报文段后敞开连贯,若没收到 A 收回的确认报文段,B 就会重传连贯开释报文段。
面试官 : 建设连贯时三次握手,为什么连贯开释要四次挥手,三次不行吗?
大彬 :因为建设连贯时,当 Server 端收到 Client 端的SYN
连贯申请报文后,能够间接发送 SYN+ACK
报文。
大彬 : 然而在敞开连贯时,当 Server 端收到 Client 端收回的连贯开释报文时,很可能并不会立刻敞开 SOCKET,所以 Server 端先回复一个 ACK
报文,通知 Client 端我收到你的连贯开释报文了。只有等到 Server 端所有的报文都发送完了,这时 Server 端能力发送连贯开释报文,之后两边才会真正的断开连接。故须要四次挥手。
面试官 : 嗯,你理解 https 吗?https 是为了解决什么问题?
独白:一点也不慌哈哈
大彬:HTTP 是明文传输,容易被黑客窃听或篡改,不平安。
大彬:HTTPS 次要解决了 HTTP 明文协定的缺点,在 HTTP 的根底上退出 SSL/TLS 协定,依附 SSL 证书来验证服务器的身份,为客户端和服务器端之间建设 SSL 通道,确保数据传输平安。
面试官:那 http 跟 https 具体有什么区别呢?
大彬:http 和 https 的区别如下:
- HTTP 是超文本传输协定,信息是 明文传输 ;HTTPS 则是具备 安全性 的 ssl 加密传输协定。
- HTTP 和 HTTPS 用的端口不一样,HTTP 端口是 80,HTTPS 是 443。
- HTTPS 协定 须要到 CA 机构申请证书,个别须要肯定的费用。
- HTTP 运行在 TCP 协定之上;HTTPS 运行在 SSL 协定之上,SSL 运行在 TCP 协定之上。
面试官 : 不错,再来问点 MySQL 相干的
面试官 : 什么状况下索引会生效?
大彬:次要有这么几种状况会导致索引生效。
- 对于组合索引,不是应用组合索引最右边的字段,则不会应用索引
- 以 % 结尾的 like 查问如
%abc
,无奈应用索引;非 % 结尾的 like 查问如abc%
,相当于范畴查问,会应用索引 - 查问条件中列类型是字符串,没有应用引号,可能会因为类型不同产生隐式转换,使索引生效
- 判断索引列是否不等于某个值时
- 对索引列进行运算
- 查问条件应用
or
连贯,也会导致索引生效
面试官:很好,今天能入职吗?
独白:马甲头盔箱子三件套?