共计 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连贯，也会导致索引生效
面试官：很好，今天能入职吗？
独白：马甲头盔箱子三件套？
