在这里写的都是正确答案，当时真实的回答情况会写在答案后面的括号里面
1.先做个自我介绍
（说了一下我的学校、年级，和怎么接触后端和平常接一些项目的事情）
2.现在学了哪些课了？
（感觉大二面试其实挺沾光的（虽然我没沾上），因为如果面试官人不错的话，会根据你所说的你学过的课来问你，这个时候你可以限定几个你很擅长的。所以！如果有同学还想大二去面字节的话！快放下你的Redis和微服务吧！把计网和操作系统复习复习好！）
3.说一下网络模型有几层？
（当时好像把OSI和TCP/IP模型说反了，上来就说TCP/IP有七层，然后只说了物理层、数据链路层、网络层、传输层和应用层，然后剩下两层支支吾吾······（大家面试说点别的也不要支支吾吾······真的很尴尬······））
4.应用层有哪些协议？
(1)域名系统(Domain Name System，DNS)：用于实现网络设备名字到IP地址映射的网络服务。
(2)文件传输协议(File Transfer Protocol，FTP)：用于实现交互式文件传输功能。
(3)简单邮件传送协议(Simple Mail Transfer Protocol, SMTP)：用于实现电子邮箱传送功能。
(4)超文本传输协议(HyperText Transfer Protocol，HTTP)：用于实现WWW服务。
(5)简单网络管理协议(simple Network Management Protocol，SNMP)：用于管理与监视网络设备。
(6)远程登录协议(Telnet)：用于实现远程登录功能。
（不知道面试官是唬我还是特地测试我，我说完FTP就说了DNS，他说：DNS？DNS是什么？然后我就懵了，忘记那几个英文了。然后他说S是指service对吧，这是一种服务。然后我就说抱歉，记错了，然后后面的也没想起来（甚至连http都没想到）。现在看来，要是我知道DNS真正的英文全称还能跟他反驳一下。所以说，面试一定要自信，自己记着是对的，不要说抱歉说错了，如果很确定，可以反驳一下，面试官也要现想的）
5.TCP三次握手过程。为什么需要三次握手？
本质在于信道本身是不可靠的，而我们需要建立可靠的连接。三次连接可以保证服务端和客户端的接收和发送能力都是正常的，并且都有建立连接的意愿。（如果不追问的话简单说，不要拖沓）
追问：那两次握手不可以吗？客户端说我想连接、服务端说可以，直接发就是了？为什么还要握一次？
（这个时候就一定要举例加提到半连接状态了。）最后一次握手不但保证了客户端的接收能力正常，而且保证了客户端目前有建立连接的意愿。如果客户端发送的是过时无效的连接请求，也就是服务端收到客户端的连接请求的时候客户端已经不想建立连接了，如果只有两次握手，那服务端就开始向一个不会接收它数据的客户端发数据了，这就是没有建立有效连接而且浪费资源。所以服务端在握完第一次手之后要进入半连接状态，等待客户端说它现在真的想接收才可以开始发送数据。（后面可以跟SYN攻击，但是要准备好相关内容，例如解决方案等等）例如SYN攻击就是用大量虚假的IP向服务端发送连接请求请求建立连接，不进行第三次握手，从而让服务端进入半连接状态而耗干服务端的资源，如果没有第三次握手，那么这些请求都会被响应，服务端就会向大量不存在的IP发送数据了。
同时。现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
（前半个问题脑子里想着图说了说，感觉还行；后半个问题硬是没想到失效的连接请求这个例子，一直绕着客户端的接收能力绕不出来了，说的很乱，具体是啥我现在也记不清了······）
6.四次挥手呢？为什么需要四次？
答"为什么需要四次，三次不可以吗的问题"同样把重点放在第三次挥手如果数据包丢失，则服务端关闭，但是客户端仍然认为服务端有信息没有发送完毕，所以可能会维持FIN-WAIT2的状态，产生对资源的浪费。
（这里都答上来了，虽然忘记后半段说的什么了，但是答的比三次握手好多了）
7.进程和线程的区别
进程是资源占有的基本单位，线程是分配和调度的基本单位。进程可以拥有很多个线程，线程隶属于进程。（线程和进程的结构区别）进程包含文本段、程序计数器、栈、数据段、堆，进程中的线程共享进程的代码、数据、文件，每个线程有自己的寄存器、堆栈。进程和线程都可以并发，但是进程上下文切换的代价要大于线程。
（这里和上述文字答的差不多，我习惯说定义之后说结构）
8.死锁发生的四个条件
互斥占用并等待非抢占循环等待
（答上来了）
9.进程和线程通信的方式。
进程：管道、命名管道、信号、信号量、共享内存、消息队列、套接字
线程：锁、信号、信号量
（进程好像少答了一个共享内存）
9.你在简历上写了用MyBatis拦截器实现了乐观锁，能说一下什么是乐观锁什么是悲观锁吗？
悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁：总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
（当时用百米赛跑讲的，说是悲观锁拿到锁才跑，乐观锁跑完了看有没有锁，但是不是很满意）
10.那你当时是在什么情况下需要乐观锁？具体又是怎么实现的？
（一个预约活动，要控制并记录预约名额，类似于这种check-and-set这种行为就需要加锁。当时用MyBatis拦截器实现了一下，但是没有成功，感觉是配置太多了没有弄明白；最后使用mp实现的，mybatisplus，这个就在config包里加一个MybatisConfig类即可。）
追问：那mp本身是怎么实现乐观锁的呢？
（当时回答的不知道，想是不是问的源码呀，我也没看过呀，，但是现在想想问的应该是加个版本号属性的问题。）
11.简历上还写了你有InnoDB调优经历，那能讲讲你是怎么调优的吗？
（首先因为个人做的都是小项目，体量比较小，而且是自己设计的，所以如果一个接口跑得特别慢，我可能首先想到的是设计问题：我有没有用特别长的字段或者varchar这种类型来作为主键？查询有没有特别多表的join啊？如果有的话会适当地反范式。还有设计合适的索引——）
12.诶，你提到索引了，能说说MySQL中有哪几种索引类型吗？
B+树，哈希索引，R-Tree索引，全文索引，和其他索引类型。
（当时说的是B+树、哈希和“当然还有其他的，但是最主要就这两个”）
13.那什么情况下适合用B+树，什么时候适合用哈希呢？
B+树支持排序和范围查找，但是哈希索引不支持。
在MySQL中，只有HEAP/MEMORY引擎表才能显式支持哈希索引(NDB也支持，但这个不常用)，InnoDB引擎的自适应哈希索引(adaptive hash index)不在此列，因为这不是创建索引时可指定的。
还需要注意到：HEAP/MEMORY引擎表在mysql实例重启后，数据会丢失。
通常，B+树索引结构适用于绝大多数场景，像下面这种场景用哈希索引才更有优势：
在HEAP表中，如果存储的数据重复度很低(也就是说基数很大)，对该列数据以等值查询为主，没有范围查询、没有排序的时候，特别适合采用哈希索引
13.数据库的ACID能说一下吗
原子性(atomicity)：一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作，要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作。
一致性(consistency)：数据库总是从一个正确的状态转换到另一个正确的状态。如果事务最终因为系统崩溃而没有提交，那事务中所做的修改也不会保存到数据库中。
隔离性(isolation)：通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。
持久性(durability)：一旦事务提交，则所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。
（一致性说的有点糊了）
14.既然提到隔离性了，那能介绍一下MySQL的几种隔离级别吗？
未提交读：事务中的修改，即使没有提交，对其他事务也是可见的。事务可以读取未提交的数据（脏读）。
提交读：一个事务开始时，只能“看见”已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别也叫不可重复读，因为两次执行同样的查询，可能会得到不一样的结果。这个级别是大多数数据库的默认隔离级别（但MySQL不是）。
可重复读：保证在同一个事务中多次读取同样的记录结果是一致的。理论上，可重复读无法解决幻读的问题。幻读指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行。MVCC（在一定程度上）解决了幻读的问题。
可串行化：最高的隔离级别，通过强制事务串行执行，避免了幻读的问题。
（说的和上面差不多，但是没提用MVCC解决幻读，所以后面又问到了）
15.那MySQL的默认隔离级别是什么呢？
可重复读。
16.那MySQL的可重复隔离级别也有幻读问题吗？
（应该用MVCC解决了，但是是一定程度上解决了。应该是在某些情况下还是会出现幻行，只是在普通情况下不会）
17.嗯？那分别是什么情况？
（一般情况就是隔离级别里说的那样，别的事务提交对当前事务的一次性读没有影响；但是如果别的事务提交了当前事务将要执行的update满足的条件的记录，那么会把刚刚提交的事务中的新记录也update了，然后再select的时候也会看到新提交的记录。）
（这里答的超级乱，感觉面试官的意思是他都不知道解决不了，应该是网上博客乱讲的，只是我现在不知道怎么解决，自己也没试过，只是道听途说，，这道题也告诉我们不要轻信网上的博客，一定要身体力行。）
18.你知道间隙锁吗？
（不知道，只是听过这个名词，意思应该是间隙锁能解决我说的问题，但是我当时是真不知道）
19.SQL语句：teacher表里有teacher_id和course_id，输出课最多的五名老师和他们的课数。
SELECT teacher_id,COUNT(course_id) AS course_num GOURP BY teacher_id ORDER BY course_num DESC LIMIT 5;
(不出所料，当时没写对，因为练都没练过，只是过了一遍）
20.冒泡排序
总的来说，八股个人感觉还可以，毕竟没有系统地准备过，只是临阵磨枪。以后真的要好好复习计网和操作系统（还没学的同学好好学！！）以后面试说话尽量简洁，我的面试官尽管这么友善了仍然能感到不耐烦，那要是去面别的不待见你的厂不得让你停啊。还有就是基本功上手一定要稳扎稳打，哪怕前面八股不会的再多一点，当面试官打开白板的时候，你就知道剩下的题目你最好在短的时间里给最好的答案。
