java面试重点总结

java⾯试重点总结

⾯试题汇总1、Java的SDK起到的作⽤

答：SDK：软件开发⼯具包（Software Development Kit) 包含JDK同时肯定包含JRE。2、进程和线程的区别

答：线程在进程下运⾏，⼀个进程可以包含多个线程，就⽐如⼀个银⾏门店，开始营业，就是进程开启，然后每个窗⼝就是处理业务，每个窗⼝就是线

程。3、进程切换会发⽣什么

答：进程的切换，实质上就是被中断运⾏进程与待运⾏进程的上下⽂切换，分为两步：1、切换新得页表，然后使⽤新得虚拟地址空间。2、切换内核栈，

加⼊新得内容（PCB控制块，资源相关），硬件剩下问切换。4、进程调度算法

答：

批处理：1. 先来先服务算法，根据进程到达时间，严格按照顺序进⾏执⾏。

2. 短任务优先算法，在排队的时候，把处理时间短的进程排在队列前⾯。

3. ⾼相应⽐优先算法，公式：相应⽐=（等待时间+要求服务时间）/要求服务时间；相应⽐⾼的算法会先执⾏。

并发：1. 时间⽚轮转算法：每个进程轮流使⽤CPU资源，如果运⾏时间结束，就阻塞进程，切换下⼀个进程

2. 优先级调度算法：每个进程设置⼀个优先级，运⾏时根据优先级的⼤⼩来进⾏调度，先调度最⼤优先级的进程。

5、TCP、UDP区别

答：TCP在连接前，通过三次握⼿来建⽴连接，⽽UDP没有握⼿机制；TCP对系统资源要求更多；UDP程序结构相对简单；TCP保证数据正确性，UDP

可能丢包，TCP保证数据顺序，UDP不保证tcp协议和udp协议的差别

TCP UDP

是否连接 ⾯向连接 ⾯向⾮连接

传输可靠性 可靠 不可靠

应⽤场合 少量数据 传输⼤量数据

速度 慢 快6、java锁，关键字区别

答：synchronized关键字和java.util.concurrent.lock.Lock类

实现层⾯不⼀样。synchronized 是 Java 关键字，JVM层⾯ 实现加锁和释放锁；Lock 是⼀个接⼝，在代码层⾯实现加锁和释放锁

是否⾃动释放锁。synchronized 在线程代码执⾏完或出现异常时⾃动释放锁；Lock 不会⾃动释放锁，需要在 finally {} 代码块显式地中释放锁

是否⼀直等待。synchronized 会导致线程拿不到锁⼀直等待；Lock 可以设置尝试获取锁或者获取锁失败⼀定时间超时

获取锁成功是否可知。synchronized ⽆法得知是否获取锁成功；Lock 可以通过 tryLock 获得加锁是否成功

功能复杂性。synchronized 加锁可重⼊、不可中断、⾮公平；Lock 可重⼊、可判断、可公平和不公平、细分读写锁提⾼效率7、公平锁、⾮公平锁

答：公平锁：多个线程按照申请锁的顺序去获得锁，线程会直接进⼊队列去排队，永远都是队列的第⼀位才能拿到锁。优点：所有的线程都能得到资源，

不会饿死在队列中。缺点：吞吐量会下降很多，队列⾥⾯除了第⼀个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很⼤。

⾮公平锁：多个线程去获取锁时，会直接尝试获取，获取不到，再进⼊等待序列，如果能获取，就直接获取。优点：可以减少CPU唤醒线程的开销，整体

的吞吐效率会⾼点，CPU也不必取唤醒所有线程，会减少唤起线程的数量。缺点：你们可能也发现了，这样可能导致队列中间的线程⼀直获取不到锁或者

长时间获取不到锁，导致饿死。8、springmvc和springboot的区别

答：springmvc是基于spring的ioc和aop开发的web框架，springboot只是在此基础上简化了springmvc的配置，通过⼀系列starter，降低了项⽬搭建的复

杂度。9、spring 的AOP⽤的什么设计模式：代理模式

三次握⼿、四次挥⼿

连接：三次握⼿；关闭：四次挥⼿seq：序列号 ：⽤来标记数据段的顺序

ack：确认号

ACK：ACK=1时确认号才有效

SYN=1：请求建⽴连接（三次握⼿）

FIN=1：请求断开连接（四次挥⼿）

第⼀次握⼿：建⽴连接时，客户端发送syn包（syn=j）到服务器，并进⼊SYN_SENT状态，等待服务器确认；SYN：同步序列编号（SynchronizeSequence Numbers）。

第⼆次握⼿：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时⾃⼰也发送⼀个SYN包（syn=k），即SYN+ACK包，此时服务器进⼊SYN_RECV状态；

第三次握⼿：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进⼊ESTABLISHED（TCP连接

成功）状态，完成三次握⼿。

个⼈总结理解记忆：

客户端：我要给你发快递了（第⼀次握⼿）

服务器：好的，我晓得了（第⼆次握⼿）

客户端：ok（我晓得你晓得了）（第三次握⼿）

四次挥⼿：

1）客户端进程发出连接释放报⽂，并且停⽌发送数据。释放数据报⽂⾸部，FIN=1，其序列号为seq=u（等于前⾯已经传送过来的数据的最后⼀个字节的

序号加1），此时，客户端进⼊FIN-WAIT-1（终⽌等待1）状态。 TCP规定，FIN报⽂段即使不携带数据，也要消耗⼀个序号。2）服务器收到连接释放报⽂，发出确认报⽂，ACK=1，ack=u+1，并且带上⾃⼰的序列号seq=v，此时，服务端就进⼊了CLOSE-WAIT（关闭等待）状

态。TCP服务器通知⾼层的应⽤进程，客户端向服务器的⽅向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数

据，客户端依然要接受。这个状态还要持续⼀段时间，也就是整个CLOSE-WAIT状态持续的时间。3）客户端收到服务器的确认请求后，此时，客户端就进⼊FIN-WAIT-2（终⽌等待2）状态，等待服务器发送连接释放报⽂（在这之前还需要接受服务器

发送的最后的数据）。4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报⽂，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能⼜发送了⼀些数据，假定此

时的序列号为seq=w，此时，服务器就进⼊了LAST-ACK（最后确认）状态，等待客户端的确认。5）客户端收到服务器的连接释放报⽂后，必须发出确认，ACK=1，ack=w+1，⽽⾃⼰的序列号是seq=u+1，此时，客户端就进⼊了TIME-WAIT（时间等

待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报⽂段寿命）的时间后，当客户端撤销相应的TCB后，才进⼊CLOSED状态。6）服务器只要收到了客户端发出的确认，⽴即进⼊CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时

间要⽐客户端早⼀些。

个⼈理解：

客户端：我们分⼿吧！！（第⼀次挥⼿）

服务器：要的我晓得了，我把你的东西全部寄给你（第⼆次挥⼿）

服务器：东西⽼⼦寄完了，你可以滚了（第三次）

客户端：好的，不要再见了！（第四次）

为什么是四次挥⼿不是三次挥⼿：

在第⼀次挥⼿中，客户端提出断开要求，但服务器可能还有数据要发送（第⼆次挥⼿），然后服务端还需要告诉客户端我信息发完了（第三次挥⼿），最

后客户端要回复服务端说知道了GC 垃圾回收

GCRoots

虚拟机栈中本地变量表中引⽤的对象

⽅法区中静态属性引⽤的变量

⽅法区中常量引⽤的对象

本地⽅法栈中引⽤的对象

算法：

标记清除：将要回收的资源进⾏标记，然后清除掉

缺点：容易造成碎⽚，因为清理的资源再内存中是分散的，所以清除过后就缺⼀块少⼀块的，所以就会产⽣⼤量的碎⽚

标记整理：标记存活的对象，将存活的对象标记全部放⼊内存的⼀端

复制整理：把空间分成两块，每次只对其中⼀块进⾏ GC。当这块内存使⽤完时，就将还存活的对象复制到另⼀块上⾯。MinorGC：复制算法

1：eden、servicorFrom 复制到 ServicorTo，年龄+1 ⾸先，把 Eden 和 ServivorFrom 区域中存活的对象复制到 ServicorTo 区域（如果有对象的年 龄

以及达到了⽼年的标准，则赋值到⽼年代区），同时把这些对象的年龄+1（如果 ServicorTo 不 够位置了就放到⽼年区）； 2：清空 eden、servicorFrom 然后，清空 Eden 和 ServicorFrom 中的对象；

3：ServicorTo 和 ServicorFrom 互换 最后，ServicorTo 和 ServicorFrom 互换，原 ServicorTo 成为下⼀次 GC 时的 ServicorFrom 区。

MajorGC :标记清除算法

⾸先扫描⼀次所有⽼年代，标记出存活的对象，然后回收没 有标记的对象。MajorGC 的耗时⽐较长，因为要扫描再回收。MajorGC 会产⽣内存碎⽚，

为了减 少内存损耗，我们⼀般需要进⾏合并或者标记出来⽅便下次直接分配。当⽼年代也满了装不下的 时候，就会抛出 OOM（Out of Memory）异常。

在 Java8 中，永久代已经被移除，被⼀个称为“元数据区”（元空间）的区域所取代。元空间 的本质和永久代类似，元空间与永久代之间最⼤的区别在

于：元空间并不在虚拟机中，⽽是使⽤ 本地内存。

默认情况下年龄到达 15 的对象会被 移到⽼⽣代中。Http

状态码：200：⼀切正常

400：客户端的问题

500：服务器问题

404：资源找不到

http请求步骤：

1. 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;

2. 解析出 IP 地址后，根据该 IP 地址和默认端⼝ 80，和服务器建⽴TCP连接;

3. 浏览器发出读取⽂件(URL 中域名后⾯部分对应的⽂件)的HTTP 请求，该请求报⽂作为 TCP 三次握⼿的第三个报⽂的数据发送给服务器;

4. 服务器对浏览器请求作出响应，并把对应的 html ⽂本发送给浏览器;

5. 释放 TCP连接;

6. 浏览器将该 html ⽂本并显⽰内容;

CAS

CAS：乐观锁的⼀种实现，通过unsafe提供硬件级别的原⼦操作，在更改数据时查看数据是否与之前相等，相等则更改。

ABA问题：三个线程初始值为A，第⼀个修改为B，第⼆个进⼊了，第三个抢先修改回A，然后第⼆个线程⽐对的时候发现没有问题，就继续修改。参考⼉

⼦去取钱，余额100，取50，然后发送了两次请求，第⼀次扣除了50，他妈给他转了50，然后第⼆个请求以为钱没变，就继续扣50。

解决办法：设置版本号

AQS：AQS(AbstractQueuedSynchronizer)，AQS是JDK下提供的⼀套⽤于实现基于FIFO等待队列的阻塞锁和相关的同步器的⼀个同步框架。这个抽象

类被设计为作为⼀些可⽤原⼦int值来表⽰状态的同步器的基类。如果你有看过类似 CountDownLatch 类的源码实现，会发现其内部有⼀个继承了AbstractQueuedSynchronizer 的内部类 Sync 。可见 CountDownLatch 是基于AQS框架来实现的⼀个同步器.类似的同步器在JUC下还有不少。(eg.

Semaphore )

数据库范式

第⼀范式：确保每列保持原⼦性：就是每个属性不能再进⾏分解。

就⽐如说地址还可以分为省、区、门牌，那么地址就不满⾜第⼀范式。

第⼆范式：再第⼀范式的基础上，表中每列必须跟主键相关，就是商品表就只有商品信息，没有其他关联信息（主要针对联合主键）