java面试题梳理整合

互斥条件，共享资源 X 和 Y 只能被一个线程占用；

请求和保持条件，线程 T1 已经取得共享资源 X，在等待共享资源 Y 的时候，不释放共享资源 X；

不可抢占条件，其他线程不能强行抢占线程 T1 占有的资源；

循环等待条件，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等待。导致死锁之后，只能通过人工干预来解决，比如重启服务，或者杀掉某个线程。

给 JVM 虚拟机分配的内存太小，实际业务需求对内存的消耗比较多

Java 应用里面存在内存泄漏的问题，或者应用中有大量占用内存的对象，并且没办法及时释放。

java.lang.OutOfMemoryError: Java heapspace ------>java 堆内存溢出，此种情况最常见，一般由于内存泄漏或者堆的大小设置不当引起。对于内存泄漏，需要通过内存监控软件查找程序中的泄露代码，而堆大小可以通过虚拟机参数-Xms,-Xmx 来修改。

java.lang.OutOfMemoryError: PermGen space 或 java.lang.OutOfMemoryError：MetaSpace ------>java 方法区，溢出了，一般出现在大量 Class，或者采用 cglib等反射机制的情况，因为这些情况会产生大量的 Class 信息存储于方法区。这种情况可以通过更改方法区的大小来解决，使用类似-XX:PermSize=64m-XX:MaxPermSize=256m 的形式修改。另外，过多的常量尤其是字符串也会导致方法区溢出。

 遇到这类问题，通常的排查方式是，先获取内存的 Dump 文件。

Dump 文件有两种方式来生成，

如果是内存泄漏，可进一步通过工具查看泄漏对象到 GC Roots 的引用链。掌握了泄漏对象的类信息和 GC Roots 引用链的信息，就可以比较准确地定位泄漏代码的位置。

如果是普通的内存溢出，确实有很多占用内存的对象，那就只需要提升堆内存空间即可。

使用数据库唯一索引的方式实现，我们可以专门创建一个消息表，里面有一个消息内容的字段并且设置为唯一索引，每次收到消息以后生成md5 值插入到这个消息表里面。一旦出现重复消息，就会抛异常，我们可以捕获这个异常来避免重复对数据做变更。

使用 Redis 里面的 setNx 命令，我们可以把当前请求中带有唯一标识的信息存储到Redis 里面，根据 setNx 命令返回的结果来判断是否是重复执行，如果是则丢弃该请求。

使用状态机的方式来实现幂等，在很多的业务场景中，都会存在业务状态的流转，并且这些状态流转只会前进，所以我们在对数据进行修改的时候，只需要在条件里面带上状态，就能避免数据被重复修改的问题。

做开发千万不能眼里只有技术细节，技术只能告诉你怎么做，而产品、业务逻辑则是告诉你做什么进入新公司以后，首先要搞清楚新公司的产品功能以及业务逻辑公司产品的用户是谁、提供的核心功能是什么、系统在上下游的地位。带着这些问题，去熟悉产品的核心功能，对项目有一个全局性把控。而了解业务逻辑，本质上是了解这个业务背后的运转模式，基于运转模式进行深入。只有在理解业务逻辑的基础上做出的技术方案，才有价值和针对性。在了解产品和业务逻辑后，我们还可以站在行业的高度对竞品有一定的了解通过阅读一些行业报告来加深对公司业务未来发展趋势的认知

刚入职，不用太着急下沉到技术细节里去。可以先从宏观上了解技术。比如当前的技术栈、使用的语言、明确使用的工具和框架，然后对照业务模型，对系统功能进行拆解。系统对外提供的接口有哪些？依赖的内部或者外部系统的接口有哪些？采用的通信方式、通信协议分别是什么？其次，项目内部分哪几个模块，每个模块的职责，最后是熟悉代码，目录结构，配置文件的位置，业务功能在源码里面的体现；有了宏观的了解之后，可以针对接口的重要程度，从头到尾绘制一下接口的时序图，顺序图，加深对核心业务的理解。

很多小伙伴加入新公司后，觉得自己对项目还不了解，不着急做需求，一直处于准备状态。但是，站在岸上，永远学不会游泳。只有带着具体问题去实践，逐步踩坑，才能快速上手；

例如在本地完成工程的搭建后，针对代码进行 debug，了解每步实现的处理逻辑和数据变化，从而完全掌握这一个小模块或功能点的实现。接下来， 就可以接一些小的需求进行开发了多做几个小需求后，对应用的实现细节就会越来越熟悉刚开始做的小需求不用求快，而是以规范为主。做完之后有了成就感，对新入职的你也是一种正向激励。

在新公司接手一个系统后，就需要以 owner的心态来对待。有些小伙伴习惯性地事无巨细都请教老员工，缺少了一份独立思考，成长的速度就会慢一些。

 遇到疑问首先有自己的判断，不论判断的是否正确，经过一次思考后，对系统的理解将会上一个台阶。在熟悉系统的过程中，可以多问一下，如果是我来设计这个项目，或者由我来实现这个功能，应该怎么做。而且现有的项目可能由于历史原因，并不是以最优方式实现，对比自己期望的做法，可以快速了解到系统这样做的深层原因。通过一次次对自己的追问中，更快地理解系统的深层背景，同时增加自身的设计能力。而自己原有的技能，也能更好地反馈在新的项目当中。

1. 第一个是 J.U.C 里面 Atomic 的原子实现，比如 AtomicInteger，AtomicLong。

2. 第二个是实现多线程对共享资源竞争的互斥性质，比如在 AQS、ConcurrentHashMap,ConcurrentLinkedQueue 等都有用到。

其原理主要基于以下几个关键概念和技术：
1. 两阶段提交（2PC）：分为准备阶段和提交阶段。在准备阶段，协调者询问参与者是否可以提交事务；在提交阶段，根据参与者的反馈决定是提交还是回滚事务。
2. 三阶段提交（3PC）：在 2PC 的基础上增加了预提交阶段，减少了阻塞的可能性。
3. 基于消息的事务：通过可靠的消息队列来保证事务的最终一致性。
4. TCC（Try-Confirm-Cancel）模式：通过自定义的尝试、确认和取消操作来实现事务。

在我之前参与的一个大型分布式电商系统中，我们综合使用了 2PC 和基于消息的事务来处理复杂的分布式事务场景。比如在订单支付和库存扣减的过程中，通过 2PC 保证了支付和库存操作的原子性，同时利用消息队列来处理可能的异常情况，确保最终一致性。

以下是一个简单的基于 2PC 的分布式事务核心代码示例（仅作示意，不包含完整的异常处理等）：
```java
import java.util.concurrent.ConcurrentHashMap;

class Coordinator {
private ConcurrentHashMap<String, Participant> participants = new ConcurrentHashMap<>();

public void addParticipant(String id, Participant participant) {
participants.put(id, participant);
}

public boolean preparePhase() {
for (Participant participant : participants.values()) {
if (!participant.prepare()) {
return false;
}
}
return true;
}

public void commitPhase() {
for (Participant participant : participants.values()) {
participant.commit();
}
}

public void rollbackPhase() {
for (Participant participant : participants.values()) {
participant.rollback();
}
}
}

interface Participant {
boolean prepare();
void commit();
void rollback();
}

class DatabaseParticipant implements Participant {
private boolean canCommit;

@Override
public boolean prepare() {
// 模拟准备操作
canCommit = true;
return canCommit;
}

@Override
public void commit() {
// 模拟提交操作
System.out.println("数据库提交成功");
}

@Override
public void rollback() {
// 模拟回滚操作
System.out.println("数据库回滚成功");
}
}
```

1. Ribbon——负载均衡2. Hystrix——服务熔断3.Zuul——网关4. Eureka——服务注册与发现5. Feign——服务调用

1. Dubbo——消息通讯2. Nacos——服务注册与发现3.Seata——事务隔离4. Sentinel——熔断降级

1. 第一，采用 Master-slave 架构，实现数据的分片和备份

2. 第二，使用 Java 编写，并对 Lucene 进行封装，隐藏了 Lucene 的复杂性

3. 第三，能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据

4. 第四，ES 提供的 Restful API，不仅简化了 ES 的操作，还支持任何语言的客户端提供 API 接口，另外 Restful API 的风格还实现了 CURD 操作、创建索引，删除索引等功能。

1. es 里面复杂的关联查询尽量别用，一旦用了性能都不太好。最好是先在 Java 系统里就完成关联，将关联好的数据直接写入 ES中

2. 避免一些太复杂的操作，比如join/nested/parent-child 搜索，不然容易出现性能问题。

3. 避免深分页查询，ES 集群的分页查询支持 from 和 size 参数，查询的时候，每个分片必须构造一个长度为 from+size 的优先队列，然后回传到网关节点，网关节点再对这些优先队列进行排序找到正确的 size 文档。当 from 足够 大的时候，就算不发生 OOM，也会影响到CPU 和带宽等，从而影响到整个集群的性能。

第一个是：通过 MVCC 可以解决读写并发阻塞问题从而提升数据并发处理能力

第二个是：MVCC 采用了乐观锁的方式实现，降低了死锁的概率

第三个是：解决了一致性读的问题也就是事务启动时根据某个条件读取到的数据，直到事务结束时，再次执行相同条件，还是读到同一份数据，不会发生变化。

a. 它是基于内存存储，在进行数据 IO 操作时，能够 10WQPS

b. 提供了非常丰富的数据存储结构，如String、List、Hash、Set、ZSet 等。

c. Redis 底层采用单线程实现数据的 IO，所以在数据算法层面并不需要考虑并发安全性，所以底层算法上的时间复杂度基本上都是常量。

1. 集群管理（凸显）Zookeeper 提供了 CP 的模型，来保证集群中的每个节点的数据一致性，当然 Zk 本身的集群并不是CP 模型，而是顺序一致性模型，如果要保证 CP 特性，需要调用｀sync｀同步方法。

2. 分布式锁（凸显）Zookeeper 提供了多种不同的节点类型，如持久化节点、临时节点、有序节点、容器节点等，其中对于分布式锁这个场景来说，Zookeeper 可以利用有序节点（插入图片）的特性来实现。除此之外，还可以利用同一级节点的唯一性特性来实现分布式锁。

3. Master 选举（凸显）Zookeeper 可以利用持久化节点来存储和管理其他集群节点的信息，从而进行 Master 选举机制。或者还可以利用集群中的有序节点特性，来实现 Master 选举。

目前主流的 Kafka、Hbase、Hadoop 都是通过 Zookeeper 来实现集群节点的主动选举。

在 Java 中，Class⽂件是由源码⽂件⽣成的，⾄于源码⽂件的内容，是每个 Java 开发者在 JavaSE 阶段的必备知识，这⾥就不再赘述了，我们可以关注⼀下 Class⽂件的格式，⽐如其中的常量池、成员变量、⽅法

Class⽂件加载到内存中，需要借助 Java 中的类加载机制。类加载机制分为装载、链接和初始化，其主要就是对类进⾏查找、验证以及分配相关的内存空间和赋值

其解决的问题就是 Class⽂件进入内存之后，该如何进⾏存储不同的数据以及数据该如何进⾏扭转。比如：Method Area 通常会储存由 Class⽂件常量池所对应的运⾏时常量池、字段和⽅法的元数据信息、类的模板信息等；Heap 是存储各种 Java 中的对象实例；Java Threads 通过线程以栈的⽅式运⾏加载各个⽅法；Native Internal Thread 可以理解为是加载运⾏native 类型的⽅法；PCRegister 则是保存每个线程执⾏⽅法的实时地址。

就是对运⾏时数据区中的数据进⾏管理和回收。回收机制可以基于不同的垃圾收集器，⽐如 Serial、Parallel、CMS、G1、ZGC等，可以针对不同的业务场景选择不同的收集器，只需要通过 JVM 参数设置即可。如果我们打开 hotspot 的源码，可以发现这些收集器其实就是对于不同垃圾收集算法的实现，核⼼的算法有 3 个：标记－清除、标记－整理、复制

 通俗理解就是翻译器，Class 的字节码指令通过 JIT Compiler 和 Interpreter 翻译成对应操作系统的CPU 指令，只不过可以选择解释执⾏或者编译执⾏，在 HotSpot JVM 默认采用的是这两种⽅式的混合。

如果我们想要找 Java 中的某个 native⽅法是如何通过 C 或者 C++实现的，那么可以通过 NativeMethod Interface 来进⾏查找，也就是所谓的 JNI 技术。通过官⽹上给出的 HotSpot 架构图，我们就能够知道 JVM 到底是如何运行的了，当然在实际操作的

在互联网发展早期，由于用户量较少、业务需求也比较简单。对于软件应用，我们只需要一台高配的服务器即可完成业务的支撑，这样的软件架构称为单体架构,随着用户量的增加，服务器的请流量也随之增加，在这个过程中单体架构会产生两个问题。

为了解决这2个问题，我们引入了集群化部署的架构，也就是把一个软件应用同时部署在多个服务器上

架构的变化带来了两个问题：

常见的实现方案有三种

负载均衡是作用在网络通信上，来实现请求的分发。而在网络架构中，基于 OSI 模型，又分为 7层网络模型

也就是意味着我们可以在网络的某些分层上做请求分发处理，因此根据这样一个特性，对于负载均衡的作用范围又可以分为2,3,4,7层负载

二层负载：基于 Mac 地址来实现请求分发，一般采用虚拟 Mac 的方式实现，服务器收到请求后，通过动态分配后端服务的实际 Mac 地址进行响应从而实现负载均衡

三层负载：基于 IP 层负载，一般通过虚拟IP 的方式实现，外部请求访问虚拟 IP，服务器收到请求后根据后端实际 IP 地址进行转发。

四层负载：通过请求报文中的目标地址和端口进行负载，Nginx、F5、LVS 等都可以实现四层负载。

七层负载：七层负载是基于应用层负载，也就是服务器端可以根据 http 协议中请求的报文信息来决定把请求分发到哪个目标服务器上，比如 Cookie、消息体、RequestHeader 等。

所谓负载均衡算法，就是决定当前客户端请求匹配到目标服务器集群中的具体哪个节点。常见的负载均衡算法有：

生产者：Producer,消息的产生者与调用端,主要负责消息所承载的业务信息的实例化,是一个队列的发起方

代理：Broker,主要的处理单元,负责消息的存储、投递,及各种队列附加功能的实现,是消息队列最核心的组成部分

消费者：Consumer,一个消息队列的终端,也是消息的调用端,具体是根据消息承载的信息，处理各种业务逻辑。

异步处理

应用解耦

流量削峰

比如中小型公司，低吞吐量的一般用ActiveMQ、RabbitMQ 较为合适，大数据高吞吐量的大型公司一般选用 Kafka 和RocketMQ。

Dubbo 是以高性能 RPC 框架，它提供了分布式架构下的服务之间通信方案，使得开发者可以不需要关心网络通信的细节。通过该框架可以使得远程服务调用方式和本地服务调用方式一样简单。Dubbo 是一款高性能、轻量级的开源 RPC框架。由 10 层模式构成，整个分层依赖由上至下。

也可以理解为三层

第一层的 Business 业务逻辑层由我们自己来提供接口和实现还有一些配置信息。

第二层的 RPC 调用的核心层负责封装和实现整个 RPC 的调用过程、负载均衡、集群容错、代理等核心功能。

Remoting 则是对网络传输协议和数据转换的封装。

Dubbo 提供了六大核心能力

Dubbo 有五种负载策略：

示意图

1.服务启动的时候，provider 和 consumer根据配置信息，连接到注册中心 register，分别向注册中心注册和订阅服务

2.register根据服务订阅关系，返回 provider 信息到consumer，同时 consumer 会把 provider信息缓存到本地。如果信息有变更，consumer 会收到来自 register 的推送

3.consumer 生成代理对象，同时根据负载均衡策略，选择一台 provider，同时定时向 monitor 记录接口的调用次数和时间信息

4.拿到代理对象之后，consumer 通过代理对象发起接口调用

5.provider 收到请求后对数据进行反序列化，然后通过代理调用具体的接口实现

Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致

Dubbo 定位服务治理、Spirng Cloud 是一个生态。

两者最大的区别是 Dubbo 底层是使用 Netty这样的 NIO 框架，是基于 TCP 协议传输的，配合以Hession 序列化完成 RPC 通信。

而SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信，相对来说，Http 请求会有更大的报文，占的带宽也会更多。但是REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。

使用分布式锁的目的，是为了保证同一时间只有一个 JVM 进程可以对共享资源进行操作。根据锁的用途可以细分为以下两类：

允许多个客户端操作共享资源，我们称为共享锁

只允许一个客户端操作共享资源，我们称为排他锁

 Redis 可以通过两种方式来实现

Zookeeper 实现分布式锁的方法比较多，我们可以使用有序节点来实现

对于 redis 的分布式锁而言，它有以下缺点：

我个人理解，Docker 是一个超轻量级的虚拟机，也是实现容器化技术的一种应用工具。Docker 是使用时下很火的 Golang 语言进行开发的，基于 Linux 内核的 cgroup，namespace，以及AUFS 类的 UnionFS 等技术，对进程进行封装隔离，属于操作系统层面的虚拟化技术。 由于隔离的进程独立于宿主和其他的隔离进程，因此也被称为容器。

资源占用小 

启动速度快

迁移更轻松

维护和拓展更轻松

运行环境一致

持续交付和部署

镜像（Image）

容器（Contaier）

仓库（Repository）

K8s 全称 Kubernetes，8 是中间 8 个字母的简称。作为一种容器自动部署、扩容以及管理的技术，我们可以简单理解其是一种容器编排技术。前身是 Borg系统，在谷歌内部已经有了十多年的使用经验。

1. Random 算法，随机移除某个 key

2. TTL 算法 ，在设置了过期时间的键中，把更早过期时间的 key 有限移除

3. LRU 算法，移除最近很少使用的 key

4. LFU 算法,最不经常使用

首先是 Producer 端，需要确保消息能够到达 Broker 并实现消息存储，在这个层面，有可能出现网络问题，导致消息发送失败，所以，针对 Producer 端，可以通过 2 种方式来避免消息丢失

acks 参数用于控制生产者发送消息后等待服务器的确认方式。acks 可以有以下几种取值及含义：
acks=0：表示生产者在发送消息后，不需要等待服务器的任何确认。这种设置下，消息可能会丢失，但能获得最高的发送性能。
acks=1：默认值。表示生产者只要收到服务器的 Leader 分区的确认就认为消息发送成功。在这种情况下，如果 Leader 分区在消息成功复制到其他副本之前崩溃，可能会导致消息丢失。
acks=all：表示生产者需要等待所有的副本（包括 Leader 和 follower 分区）都确认接收到消息后，才认为消息发送成功。这能最大程度地保证消息不丢失，但会对性能有一定影响。
综合考虑我们项目对消息可靠性的高要求，以及对性能的可接受程度，选择将 acks 设置为 all 以确保消息不丢失。

远程调用是指跨进程的功能调用，跨进程可以理解成一个计算机节点的多个进程，或者多个计算机节点的多个进程。

全称为 Remote Procedure Call，翻译过来就是远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议，凡是符合该协议的框架，我们都可以称它为 RPC 框架。关于 RPC 协议，通俗来讲就是，A 计算机提供一个服务，B 计算机可以像调用本地服务那样调用 A 计算机的服务。要实现 RPC，需要通过网络传输数据，并对调用的过程进行封装。

 作为底层传输协议。RPC 强调的是过程调用，调用的过程对用户而言是透明的，用户不需要关心调用的细节，可以像调用本地服务一样调用远程服务。

一个完整的 RPC 架构里面包含了四个核心的组件，分别是 Client ,Server,Client Stub 以及 Server Stub：

目前比较流行的开源 RPC 框架有 Google的 gRPC，Facebook 的 Thrift，阿里巴巴的 Dubbo。

RPC 的运用场景和优势

a. 线程池提供了一个 isTerminated(）方法，可以判断线程池的运行状态，我们可以循环判断isTerminated(）方法的返回结果来了解线程池的运行状态，一旦线程池的运行状态是Terminated，意味着线程池中的所有任务都已经执行完了。想要通过这个方法获取状态的前提是，程序中主动调用了线程池的shutdown(）方法。在实际业务中，一般不会主动去关闭线程池，因此这个方法在实用性和灵活性方面都不是很好。

b. 在线程池中，有一个 submit(）方法，它提供了一个 Future 的返回值，我们通过Future.get(）方法来获得任务的执行结果，当线程池中的任务没执行完之前，future.get(）方法会一直阻塞，直到任务执行结束。因此，只要future.get(）方法正常返回，也就意味着传入到线程池中的任务已经执行完成了！

c. 可以引入一个 CountDownLatch 计数器，它可以通过初始化指定一个计数器进行倒计时，其中有两种方法分别是 await(）阻塞线程，以及 countDown(）进行倒计时，一旦倒计时归零，所以被阻塞在 await(）方法的线程都会被释放。基于这样的原理，我们可以定义一个CountDownLatch 对象并且计数器为 1，接着在线程池代码块后面调用 await(）方法阻塞主线程，然后，当传入到线程池中的任务执行完成后，调用 countDown(）方法表示任务执行结束。最后，计数器归零 0，唤醒阻塞在 await(）方法的线程。

原子性呢，是指当一个线程执行一系列程序指令操作的时候，它应该是不可中断的，因为一旦出现中断，站在多线程的视角来看，这一系列的程序指令会出现前后执行结果不一致的问题。就是一段程序只能由一个线程完整地执行完成，而不能存在多个线程干扰。

CPU 的上下文切换，是导致原子性问题的核心，而 JVM 里面提供了Synchronized 关键字来解决原子性问题。

可见性，就是说在多线程环境下，由于读和写是发生在不同的线程里面，有可能出现某个线程对共享变量的修改，对其他线程不是实时可见的。导致可见性问题的原因有很多，比如 CPU的高速缓存、CPU 的指令重排序、编译器的指令重排序。

 有序性，指的是程序编写的指令顺序和最终CPU 运行的指令顺序可能出现不一致的现象，这种现象也可以称为指令重排序，所以有序性也会导致可见性问题。可见性和有序性可以通过 JVM 里面提供了一个 Volatile 关键字来解决。

i. 开放定址法，也称为线性探测法，就是从发生冲突的那个位置开始，按照一定的次序从hash 表中找到一个空闲的位置，然后把发生冲突的元素存入到这个空闲位置中。ThreadLocal 就用到了线性探测法来解决hash 冲突的。像这样一种情况（如图），在 hash 表索引 1的位置存了一个 key=name，当再次添加key=hobby时，hash 计算得到的索引也是1，这个就是 hash 冲突。而开放定址法，就是按顺序向前找到一个空

ii. 链式寻址法，这是一种非常常见的方法，简单理解就是把存在 hash 冲突的 key，以单向链表的方式来存储，比如 HashMap 就是采用链式寻址法来实现的。

iii.再 hash 法，就是当通过某个 hash 函数计算的 key 存在冲突时，再用另外一个hash 函数对这个 key 做 hash，一直运算直到不再产生冲突。这种方式会增加计算时间，性能影响较大。

iv.建立公共溢出区， 就是把 hash 表分为基本表和溢出表两个部分，凡是存在冲突的元素，一律放入溢出表中。

e. HashMap 在 JDK1.8 版本中，通过链式寻址法+红黑树的方式来解决 hash 冲突问题，其中红黑树是为了优化 Hash 表链表过长导致时间复杂度增加的问题。当链表长度大于 8 并且hash表的容量大于 64 的时候，再向链表中添加元素就会触发转化。

排他锁,是存在多线程竞争同一共享资源时，同一时刻只允许一个线程访问该共享资源，也就是多个线程中只能有一个线程获得锁资源，比如 Lock 中的 ReentrantLock 重入锁实现就是用到了 AQS 中的排它锁功能。

共享锁也称为读锁，就是在同一时刻允许多个线程同时获得锁资源，比如CountDownLatch 和Semaphore 都是用到了 AQS 中的共享锁功能。

好的，我用三点来简单地介绍下 Netty

第一：Netty 是一个 基于 NIO 模型的高性能网络通信框架，其实可以认为它是对 NIO 网络模式。型的封装，提供了简单易用的 API，我们可以利用这些封装好的 API 快速开发自己的网络程序。

第二：Netty 在 NIO 的基础上做了很多优化，比如零拷贝机制、高性能无锁队列、内存池等，因此性能会比 NIO 更高。

第三：Netty 可以支持多种通信协议，如Http、WebSocket 等，并且针对数据通信的拆包黏包问题，Netty 内置了拆包策略。

Bootstrap 负责客户端启动并用来连接远程netty server

ServerBootStrap 负责服务端监听，用来监听指定端口，

Channel 是负责网络通信的载体

EventLoopGroup 本质上是一个线程池，主要负责接收 I/O 请求，并分配线程执行处理请求。

EventLoop。相当于线程池中的线程

ChannelPipeline 负责将多个Channelhandler 连接在一起

ChannelHandler 针对 IO 数据的处理器，数据接收后，通过指定的 Handler 进行处理。

ChannelHandlerContext 用来保存ChannelHandler 的上下文信息

 Netty 提供了三种 Reactor 模型的支持

Reactor 模型有三个重要的组件：

单 Reactor 单线程模型

多线程单 Reactor 模型

多线程多 Reactor 模型

1. 动态代理本身的使用场景或者需求，只是对原始实现的一个拦截，然后去做一些功能的增强或者扩展。而实际的开发模式也都是基于面向接口来开发，所以基于接口来实现动态代理，从需求和场景都是吻合的。当然确实可能存在有些类没有实现接口的，那这个时候，JDK动态代理确实无法满足。

2. 在 Java 里面，类的继承关系的设计，更多的是考虑到共性能力的抽象，从而提高代码的重用性和扩展性，而动态代理也是在做这样一个事情，它封装了动态代理类生成的抽象逻辑、判断一个类是否是动态代理类、InvocationHandler 的持有等等，那么把这些抽象的公共逻辑放在 Proxy 这个分类里 面，很显然是一个比较正常的设计思路。

 一、首先是异常的本质受检异常和非受检异常，都是继承自Throwable 这个类中，分别是 Error 和Exception，Error 是程序报错，系统收到无法处理的错误消息，它和程序本身无关。Excetpion 是指程序运行时抛出需要处理的异常信息如果不主动捕获，则会被 jvm 处理。

二、然后是对受检异常和非受检异常的定义前面说过受检异常和非受检异常均派生自Exception 这个类。

三、最后我还可以说下他们优点和缺点

1. 引入 Starter 启动依赖组件的时候，这个组件里面必须包含@Configuration 配置类，在这个配置类里面通过@Bean 注解声明需要装配到IOC 容器的 Bean 对象。

2. 这个配置类是放在第三方的 jar 包里面，然后通过 SpringBoot 中的约定优于配置思想，把这个配置类的全路径放在 classpath:META-INF/spring.factories 文件中。这样SpringBoot 就可以知道第三方 jar 包里面的配置类的位置，这个步骤主要是用到了Spring 里面的 SpringFactoriesLoader来完成的。

3. SpringBoot 拿到第三方 jar 包里面声明的配置类以后，再通过 Spring 提供的ImportSelector 接口，实现对这些配置类的动态加载。在我看来，SpringBoot 是约定优于配置这一理念下的产物，所以在很多的地方，都会看到这类的思想。

将两个或多个Bean 互相之间持有对方的引用就会发生循环依赖。循环的依赖将会导致陷入死循环。这是 Spring 发生循环依赖的原因。

循环依赖有三种形态：

Spring 中设计了三级缓存来解决循环依赖问题，当我们去调用 getBean(）方法的时候，Spring 会先从一级缓存中去找到目标Bean，如果发现一级缓存中没有便会去二级缓存中去找，而如果一、二级缓存中都没有找到，意味着该目标 Bean 还没有实例化。于是，Spring 容器会实例化目标 Bean然后，将目标 Bean 放入二级缓存中，同时，加上标记是否存在循环依赖。如果不存在循环依赖便会将目标 Bean 存入到二级缓存，否则，便会标记该 Bean 存在循环依赖，然后将等待下一次轮询赋值，也就是解析@Autowired 注解。等@Autowired 注解赋值完成后（PS：完成赋值的 Bean 称为成熟Bean） ，会将目标 Bean 存入到一级缓存。

Spring 一级缓存中存放所有的成熟 Bean，二级缓存中存放所有的早期 Bean，先取一级缓存，再去二级缓存。

循环依赖指的是两个或多个对象之间相互依赖，形成一个封闭的依赖环。
在 Spring 框架中，解决循环依赖的主要方式有以下几种：
三级缓存机制：Spring 创建对象时，会先将正在创建的对象放入三级缓存中。当需要解决循环依赖时，从缓存中获取半成品对象来完成依赖注入。
提前暴露对象：在创建对象的过程中，会提前将创建中的对象暴露出来，以便在其他对象依赖时能够获取到。

这个阶段主要的作用是，Bean 在开始加载之前，需要从上下文和相关配置中解析并查找 Bean 有关的扩展实现

比如像｀init-method`-容器在初始化 bean时调用的方法、destory-method`容器在销毁 bean 时调用的方法。

以及，BeanFactoryPostProcessor 这类的bean 加载过程中的前置和后置处理。

这些类或者配置其实是 Spring 提供给开发者，用来实现 Bean 加载过程中的扩展机制，在很多和 Spring集成的中间件中比较常见，比如 Dubbo。

这个阶段主要是通过反射来创建 Bean 的实 例对象，并且扫描和解析 Bean 声明的一些属性。

如果被实例化的 Bean 存在依赖其他 Bean对象的情况，则需要对这些依赖 bean 进行对象注入。比如常见的｀@Autowired`setter 注入等依赖注入的配置形式。同时，在这个阶段会触发一些扩展的调用，比如常见的扩展类：BeanPostProcessors（用来实现 bean初始化前后的扩展回调）、 InitializingBean（这个类有一个afterPropertiesSet()，这个在工作中也比较常见）、BeanFactoryAware 等等。 InitializingBean（这个类有一个afterPropertiesSet()，这个在工作中也比较常见）、BeanFactoryAware 等等。

容器缓存阶段主要是把 bean 保存到容器以及 Spring 的缓存中，到了这个阶段，Bean就可以被开发者使用了。这个阶段涉及的操作，常见的有，init-method｀这个属性配置的方法， 会在这个阶段调用。

以及像 BeanPostProcessors 方法中的后置 处理器方法如：postProcessAfterInitialization，也会在这个阶段触发。

当 Spring 应用上下文关闭时，该上下文中的所有 bean 都会被销毁。如果存在 Bean 实现了 DisposableBean 接口，或者配置了｀destory-method｀属性，会在这个阶段被调用。

REQUIRED：默认的 Spring 事务传播级别，如果当前存在事务，则加入这个事务，如果不存在事务，就新建一个事务。

REQUIRE_NEW：不管是否存在事务，都会新开一个事务，新老事务相互独立。外部事务抛出异常回滚不会影响内部事务的正常提交。

NESTED：如果当前存在事务，则嵌套在当前事务中执行。如果当前没有事务，则新建一个事务，类似于 REQUIRE_NEW。

SUPPORTS：表示支持当前事务，如果当前不存在事务，以非事务的方式执行。

NOT_SUPPORTED：表示以非事务的方式来运行，如果当前存在事务，则把当前事务挂起。

MANDATORY：强制事务执行，若当前不存在事务，则抛出异常.

NEVER：以非事务的方式执行，如果当前存在事务，则抛出异常。

硬件和操作系统层面的优化

架构设计层面的优化

MySQL 程序配置优化

SQL 优化

第一点 对于一个数据库来说存储的数据量会比较多，导致索引也很大因此需要将索引存储在磁盘，但是磁盘的 IO 操作又非常少，所以提高索引效率的关键在于减少磁盘 IO 的次数。

举个例子 对于 31 个节点的树来说 ，一个 5阶 B+Tree 的高度是 3 一个红黑树的最小高度是 5，树的高度基本决定了磁盘的 IO 次数 ，所以使用 B+Tree 性能要高很多

第二点 B+Tree 有个特点是相邻的数据在物理上也是相邻的，因为 B+Tree 的 node 的大小设为一个页，而一个节点上存有多个相邻的关键字和分支信息，每个节点只需要一次 IO就能完全载入，相当于一次 IO载入了多个相邻的关键字和分支，而红黑树不具有这个特性，红黑树中大小相邻的数据，在物理结构上可能距离相差很大。由于程序的局部性原理，如果我们在索引中采用了预加载的技术，每次磁盘访问的时候除了将访问到的页加载到磁盘，我们还可以基于局部性原理加载，几页相邻的数据到内存中，而这个加载是不需要消耗多余磁盘 IO 时间的。

因此 基于局部性原理，以及 B+Tree 存储结好的关于普通人和高手的回答谁的回答较好

表结构与索引

SQL 语句优化

Mysql 参数优化

硬件及系统配置

加索引，增加索引是一种简单高效的手段，但是需要选择合适的列，同时避免导致索引失效的操作，比如 like、函数等。

避免返回不必要的数据列，减少返回的数据列可以提高查询的效率。

根据查询分析器适当优化 SQL 的结构，比如是否走全表扫描、避免子查询等

分库分表，在单表数据量较大或者并发连接数过高的情况下，通过这种方式可以有效提升查询效率 

读写分离，针对读多写少的场景，这样可以保证写操作的数据库承受更小的压力，也可以缓解独占

1. 主库的更新事件（update、insert、delete）被写到 binlog

2. 从库发起连接，连接到主库。

3. 此时主库创建一个 binlog dump thread，把 binlog 的内容发送到从库。

4. 从库启动之后，创建一个 I/O 线程，读取主库传过来的 binlog 内容并写入到 relaylog

5. 从库还会创建一个 SQL 线程，从 relaylog 里面读取内容，从Exec_Master_Log_Pos 位置开始执行读取到的更新事件，将更新内容写入到slave 的 db主从数据同步涉及网络数据传输，由于网络通信的延迟以及从库数据处理的效率问题， 就会导致主从数据同步延迟的情况。

设计一主多从来分担从库压力，减少主从同步延迟问题

如果对数据一致性要求高，在从库存在延迟的情况下，可以强制走主库查询数据

可以在从库上执行 show slave status 命令，获取 seconds_behind_master 字段的延迟时间，然后通过 sleep 阻塞等待固定时间后再次查询通过并行复制解决从库复制延迟的问题

优点：合理地增加索引，可以提高数据查询的效率，减少查询时间有一些特殊的索引，可以保证数据的完整性，比如唯一索引

缺点：创建索引和维护索引需要消耗时间索引需要额外占用物理空间对创建了索引的表进行数据的增加、修改、删除时，会同步动态维护索引，这个部分会造成性能的影响

主键索引：数据列不允许重复，不允许为NULL，一个表只能有一个主键。

唯一索引：数据列不允许重复，允许为NULL 值，一个表允许多个列创建唯一索引。

普通索引：基本的索引类型，没有唯一性的限制，允许为 NULL 值。

全文索引：是目前搜索引擎使用的一种关键技术，对文本的内容进行分词、搜索。

覆盖索引：查询列要被所建的索引覆盖，不必读取数据行

组合索引：多列值组成一个索引，用于组合搜索，效率大于索引合并

1. 使用场景不同，

2. 记录的信息不同，

3. 记录的时机不同

我理解的可见性，是指当某一个线程对共享变量的修改，其他线程可以立刻看到修改之后的值。其实这个可见性问题，我认为本质上是由几个方面造成的。

指令重排序，所谓重排序，就是指令的编写顺序和执行顺序不一致，在多线程环境下导致可见性问题。指令重排序本质上是一种性能优化的手段，它来自几个方面。

CPU 层面，针对 MESI 协议的更进一步优化去提升 CPU 的利用率，引入了 StoreBuffer机制，而这一种优化机制会导致 CPU 的乱序执行。当然为了避免这样的问题，CPU 提供了内存屏障指令，上层应用可以在合适的地方插入内存屏障来避免 CPU 指令重排序问题。编译器的优化，编译器在编译的过程中，在 不改变单线程语义和程序正确性的前提下，对指令进行合理的重排序优化来提升性能。

所以，如果对共享变量增加了 volatile 关键字，那么在编译器层面，就不会去触发编译器优化，同时在JVM 里面，会插入内存屏障指令来避免重排序问题。