首页  思维导图  详情

JAVA

2021-10-09 11:26:13   7  举报





AI智能生成

为你推荐

查看更多



java

JAVA

JAVA面试全方位的知识总结

作者其他创作

大纲/内容

证明这消息是你发的

证明这消息内容确实是完整的---也就是没有经过任何形式的篡改（包括替换、缺少、新增）

RSA数字签名算法

JMS

JMS模型

消息事务

ActiveMQ

是什么

应用场景

特点

1.基本介绍

Kafka节点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。

Broker

Topic是用于存储消息的逻辑概念，可以看作一个消息集合。每个topic可以有多个生产者向其推送消息，也可以有任意多个消费者消费其中的消息。每个topic可以划分多个分区（每个Topic至少有一个分区），同一topic下的不同分区包含的消息是不同的

Topic

topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列

Partition

partition物理上由多个segment组成，每个Segment存着message信息

Segment

生产message发送到topic

Producer

Consumer

Consumer Group

Kafka文件存储机制

消息发送可靠性

ISRISR（副本同步队列）

副本机制

消息存储的可靠性

消息可靠性

2.基本概念

Producer在发布消息

ACK前需要保证有多少个备份

如何处理所有Replica都不工作

数据备份

Kafka “各自为政” Leader Eclection

Kafka基于 Controller 的 Leader Election

领导选举Leader Election算法

3.高可用

high-level api

Sample-api

Consumer group

4.消费者

5.Leader Eclection

1.顺序写的方式存储数据

2.批量发送

3.零拷贝

4.数据压缩

6.kafka的高吞吐量的因素

7.日志保留策略

kafka

RocketMQ 逻辑部署结构

RocketMQ 数据存储结构

RocketMQ 物理部署结构

部署架构

技术架构

RocketMQ集群工作流程

NameServer保证AP

架构设计

整体架构

原理：同一类消息发送到相同的对列即可，为了保证先发送的消息先存储到对列，必须使用同步发送

生成消息的顺序性

原理：同一个消息对列只允许消费者中的一个消费线程拉取消息，顺序消费消费线程请求到broker时会先申请锁

顺序消费

顺序消息

消息幂等性

顺序写盘

数据零拷贝

消息实时投递

高性能设计

消息发送的重试机制

故障规避机制

消息发送的高可用

消息持久化（同步刷盘、异步刷盘）

主从复制

读写分离机制

消息存储的高可用

消费重试机制

消息ACK机制来保证

Broker集群部署

集群管理的高可用

消息消费的高可用

高可用设计

RocketMQ

主流消息中间件

1.MQ消息中间件在分布式系统中的作用

2.如何保证消息队列的高可用

3.如何保证消息消费的幂等性？

4.如何保证消息的可靠性传输？

5.如何保证消息的顺序性

面试常问的问题

消息中间件

原理：反射+XML

控制反转，IOC容器负责实例化、定位、配置应用程序中的对象及建立这些对象间的依赖。交由Spring来管理这些，实现解耦

IOC

2.AOP

原理

3.SpringMVC

图片

Spring启动，查找并加载需要被Spring管理的bean，进行Bean的实例化

1.实例化

Bean实例化后对将Bean的引入和值注入到Bean的属性中

2.填充属性

1.BeanNameAware

2.BeanFactoryAware

3.ApplicationContextAware

3.执行Aware接口

1.实现InitializingBean接口

2.使用@PostConstruct注解

3.xml中通过init-method属性指定初始化方法

4.初始化

指bean已经准备就绪、可以被应用程序使用了，此时bean会一直存在于Spring容器中

5.可用状态

1.实现DisposableBean接口

2.使用@PreDestroy注解

3.xml中通过destroy-method属性指定

6.销毁

InstantiationAwareBeanPostProcessorAdapter

7.扩展点

基本流程

循环依赖

4.Bean的生命周期

Spring声明式事务管理，核心实现就是基于Aop

5.Spring事务

第一部分进行SpringApplication的初始化模块，配置一些基本的环境变量、资源、构造器、监听器，new

第二部分实现了应用具体的启动方案，包括启动流程的监听模块、加载配置环境模块、及核心的创建上下文环境模块

第三部分是自动化配置模块，该模块作为springboot自动配置核心

流程

自动化配置

https://www.cnblogs.com/trgl/p/7353782.html

1.Spring Boot启动流程分析

2.@SpringBootApplication注解的意思

3.SpringBoot源码解析专题

4.Spring Boot

Eurka基本工作流程

Eureka Server注册中心服务端

Eureka Client：注册中心客户端

Renew: 服务续约

Eureka 分区

Eureka 核心概念

Eureka 集群原理

Eureka 如何保证 AP

自我保护机制

作为服务注册中心，Eureka比Zookeeper好在哪里

1.服务发现与注册Eureka

2.客服端负载均衡Ribbon

熔断器模式

子主题

命令模式

Hystrix Metrics的实现

Hystrix的内部处理逻辑

使用Fallback() 提供降级策略

Hystix原理

线程池（默认）

信号量

比较

Hystrix隔离策略

3.断路器Hystrix

4.服务网关SpringCloud GateWay

6.OpenFeign 一种声明式、模板化的HTTP客户端。

使用滑动计数器限流

1.总体介绍

2.Sentinel基本概念

流量控制设计理念

流量控制

3.Sentinel功能和设计理念

1.限流流程

2.工作原理

4.工作原理分析

7.服务限流与熔断：sentinel

官网地址

Nacos架构

基本架构及概念

逻辑架构及其组件介绍

服务提供者和NameServer源码流程图

服务注册

服务地址的获取

服务地址变化的感知

解读Nacos源码

注册中心的原理

动态监听

客户端核心源码解析

服务端主要流程

Nacos配置管理原理分析

Nacos原理分析

8.nacos服务注册与配置中心

9.分布式事务框架Seata

5.SpringCloud

Spring

#{}和${}的区别是什么

框架原理

一级二级缓存

MyBatis

Shiro是什么

Subject

SecurityManager

Realm

Authenticator

Authorizer

Session Manager

主要组件

Shiro 运行原理

shiro

服务调用

服务是围绕服务提供方和服务消费方的，服务提供方实现服务，而服务消费方调用服务

服务定义

服务监控

远程通信与信息交换

目的

设计模型

RPC

失败自动切换，当出现失败，重试其它服务器。(默认)

Failover Cluster

快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

Failfast Cluster

失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

Failsafe Cluster

失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

Failback Cluster

并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=”2”来设置最大并行数。

Forking Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0 开始支持) 通常用于通知所有提供者更新缓存或日志等本地资源信息。

Broadcast Cluster

Dubbo 的客户端和服务端有三种连接方式，分别是：广播，直连和使用 zookeeper 注册中心。

Dubbo 的连接方式

重试策略

加权随机算法 Random LoadBalance

加权轮询负载均衡 RandomLoadBalance

最小活跃数负载均衡 LeastActive LoadBalance

ConsistentHash LoadBalance

dubbo提供的四种负载均衡策略

负载均衡算法

http://shiyanjun.cn/archives/325.html

dubbo

zookeeper维护了一个类似文件系统的数据结构

四种节点

文件系统

客户端监听它关心的目录节点，节点变化时通知客户端

通知机制

什么是Zab协议

Zab协议需要做到什么

1.选举阶段（Leader Election）

2.发现阶段（Descovery）

3.同步阶段（Synchronization）

4、广播阶段（Broadcast）

Zab 的四个阶段

1.选举（Fast Leader Election）

2.恢复（Recovery Phase）

3.广播（Broadcast Phase）

zookeeper的zab协议的具体实现

崩溃恢复

实现原理

消息广播

Zab协议的基本使用情景

ZooKeeper的Zab一致性协议

事务请求的处理方式

Zookeeper保证CP

Leader Election

Zookeeper

源码分析

12.框架

1. B+树的磁盘读取代价低

2. B+树的查询效率更加稳定

3. B+树便于执行扫库操作

为什么MySQL InnoDB中的B+树索引

B+的特性

B+树

左旋

变色

右旋

红黑树插入总结

红黑树

二叉查找树（BST）

B-树的特性

B树

树

13.算法和数据结构

总体概述

1.HashMap原理

JDK1.8中 ConcurrentHashMap 中的CAS 和 synchronized是如何使用的

添加数据的过程

JDK1.7版本的ConcurrentHashMap的实现原理

2.ConcurrentHashMap

3.Set

4.Queue

5.equals()与hashCode()

6. List、 Set 和 Map 的初始容量和加载因子

1.集合框架

双亲委派模型

具体过程

什么情况下需要开始类加载过程的第一个阶段加载

JAVA中执行顺序

程序的赋值步骤

2.java类加载机制

程序运行期间发现更多的类及其属性的机制。

通过反射机制访问java对象的属性，方法，构造方法等。

Java程序中的各个Java类属于同一类事物，描述这类事物的Java类名就是Class

Class类代表Java类，它的各个实例对象代表各类的字节码，请注意一个Class对象实际上表示的是一个类型。而这个类型未必一定是一种类，例如int不是类，但int.class是一个Class类型的对象。Class对象实际上是个泛型类，例如 Employee.class的类型Class<Employee>.

对象.getClass()

Class.forName(\"类名\")

类名.class

获取Class实例方式

3.java反射

序列化算法一般步骤

Java如何实现序列化和反序列化

实现序列化的要求

相关注意事项

serialVersionUID

4.java序列化

Java异常类层次结构图

分类

异常分类

异常处理的原则

5.JAVA异常

按操作⽅式分类结构图

按操作对象分类结构图

6. Java 中 IO 流

1.java基础

1.开闭原则

2.里氏代换原则（抽象化）

3.依赖倒转原则

4.迪米特法则（最少知道原则）

5.单一职责原则

6.接口隔离原则

7.合成复用原则

1.设计模式的七大原则

工厂方法模式

抽象工厂模式

单例模式

建造者模式

原型模式

2.创建者模式

适配器模式

装饰器模式

代理模式

外观模式

桥接模式

享元模式

组合模式

3.结构型模式

4.行为型模式

1.23种设计模式概述

1.单例模式

1.工厂方法模式

2.抽象工厂方法模式

2.工厂方法

1.Aspectj静态代理

1.jdk动态代理

2.cglib动态代理

2.动态代理（原理：反射）

3.类图

3.代理模式

4.模板模式

5.组合模式

6.责任链模式

7.包装器模式

8.委派模式

9.桥梁模式

10.门面模式

11.享员模式

12.策略模式

2.常用的设计模式

模板模式

责任链模式-tomcat过滤器

3.项目中用到的设计模式

4.框架中用到的设计模式

2.设计模式

3.JVM

nio的实现

图片1

图片2

1.http协议组成

2.http协议请求方式

3.http状态码

HTTPS工作流程

数字证书认证机构的业务流程

4.https超文本传输安全协议

我们经常把socket翻译为套接字，socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用以实现进程在网络中通信。

5.Sokect

TCP是一个双向通信协议，通信双方都有能力发送信息，并接收响应。如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认

为什么不能两次握手

为什么连接的时候是三次握手，关闭的时候却是四次握手

过程

为什么要三次握⼿

三次握手

为什么要四次挥⼿

四次挥⼿

6.三次握手四次挥手

2.http相关

1.实现原理

2.实现一个RPC框架

3.Netty之TCP粘包/拆包

4.Netty之编解码技术

5.Netty之私有协议栈开发

6.轻量级分布式RPC框架--NettyRpc

3.netty

4.webservice

5.hessian

RPC(远程过程调用协议)，程序可以使用这个协议请求网络中另一台计算机上的程序的服务而不需要知道具体的网络细节。位于网络层的第五层。

6.RPC

REST 风格

主要原则

在 Restful 架构中，所有的接口应当采用面向资源的接口设计，即对于接口的访问地址指向其 URI 地址。

面向资源

表述性

状态转移

具体实现

6.Restful

7.键入网址后，期间发生了什么

4.网络编程

5.并发编程

Redis优点

Redis快的主要原因

String

Hash（哈希)键值对集合

List（列表）

Set（集合）

Zset 有序集合

支持的类型及每个类型的使用场景

Redis数据类型

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照

RDB

AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。

AOF

redis持久化

定时删除

惰性删除

定期删除

Redis采用的过期策略

Redis数据过期策略详解

主从模式

哨兵模式

Redis集群（cluster）

Redis集群方式

Redis的发布订阅

redis 内存淘汰机制

redis 的线程模型

更新一致性问题

1.redis

固定集合

mongodb主从复制

副本集

分片

MongoDB 主从复制，副本集，分片

2.mongodb

键值(Key-Value)存储数据库

列存储数据库

图形(Graph)数据库

文档型数据库

NoSQL聚合数据模型

6.NoSQL

1NF

2NF

3NF

范式

MySQL的缓存默认是关闭的

MySQL 8.0中，查询缓存已经被移除了

查询缓存

1、查询缓存

主要做的事情是对语句基于SQL语法进行词法和语法分析和语义的解析

2、解析器生成解析树

3、预处理再次生成解析树

根据解析树生成不同的执行计划（ExecutionPlan），然后选择一种最优的执行计划，MySQL里面使用的是基于开销（cost）的优化器，那种执行计划开销最小，就用哪种。

优化器最终会把解析树变成一个查询执行计划，查询执行计划是一个数据结构。

Explain的结果也不一定最终执行的方式

4、查询优化器

5、查询执行计划

如果对数据一致性要求比较高，需要事务支持，可以选择InnoDB

如果数据查询多更新少，对查询性能要求比较高，可以选择MyISAM

如果需要一个用于查询的临时表，可以选择Memory

如何选择存储引擎

存储引擎

6、查询执行引擎

7、查询数据返回结果

具体流程

1. （一条查询 SQL 语句是如何执行的）执行流程

连接方式：长连接或者短连接

2.通信协议

MySQL使用了半双工的通信方式

3.通信方式

缓冲池 Buffer Pool

redo Log Buffer

undo log

bin log

4.一条更新 SQL 是如何执行的

1.MySQL的架构与内部模块

实现

1、原子性：数据库事务不可分割的单位，我们对数据库的一系列的操作，要么都是成功

2、一致性：事务的操作不会改变数据库的状态，比方说唯一约束

3、隔离性：事务是相互不可见的

4、持久性：事务一旦提交，即使宕机也是能恢复的

1.特性

1、扁平事务：使用最频繁的事务，要么都成功提交，要么都失败回滚

2、带有扁平点的扁平事务：允许事务回滚到同一个事务中比较早的一个状态

3、链事务：回滚到最近的一个保存点，在所有的事务都提交之后才会释放锁，并且下一个事务的开始需要上一个事务来进行通知

4、嵌套事务：树结构，只有当父级事务提交之后子级事务才会提交，任意一个父级事务的回滚都会导致下面的子级事务回滚

5、分布式事务：操作两个不同的数据库，使其实现数据的同步，例如将中国银行的钱转到工商银行，这个不同银行的不同数据库，为分布式事务

2.分类

1.脏读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新，然后B回滚操作，那么A读取到的数据是脏数据。

2.不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。

3.幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

3.事务问题

1.读未提交（READ UNCOMMITTED）：未提交读隔离级别也叫读脏，就是事务可以读取其它事务未提交的数据。

2.读已提交（READ COMMITTED）：在其它数据库系统比如 SQL Server 默认的隔离级别就是提交读，已提交读隔离级别就是在事务未提交之前所做的修改其它事务是不可见的。

3.可重复读（REPEATABLE READ）：保证同一个事务中的多次相同的查询的结果是一致的，比如一个事务一开始查询了一条记录然后过了几秒钟又执行了相同的查询，保证两次查询的结果是相同的，可重复读也是 mysql 的默认隔离级别。

4.可串行化（SERIALIZABLE）：可串行化就是保证读取的范围内没有新的数据插入，比如事务第一次查询得到某个范围的数据，第二次查询也同样得到了相同范围的数据，中间没有新的数据插入到该范围中。

4.隔离级别

自动开启

手动开启事务也有几种方式，一种是用begin；一种是用start transaction。

手动开启事务

还有一种情况，客户端的连接断开的时候，事务也会结束。

5. 数据库什么时候会出现事务

基于锁的并发控制LockBased Concurrency Control（LBCC）

多版本的并发控制 Multi Version Concurrency Control（MVCC）

两大实现方案

6. MySQL InnoDB 对隔离级别的支持

数据库读一致性问题

行锁的原理

共享锁（s-行锁）：又称读锁

排他锁（Ｘ-行锁）：又称写锁。

意向共享锁（IS）：事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。

意向排他锁（IX）：事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

意向锁(意向锁都是表锁)

MySQL InnoDB 锁的基本类型

记录锁

间隙锁

临键锁

四个事务隔离级别的实现

锁的算法

（1）同一时刻只能有一个事务持有这把锁

（2）其他的事务需要在这个事务释放锁之后才能获取锁，而不可以强行剥夺

（3）当多个事务形成等待环路的时候，即发生死锁。

死锁的产生条件

死锁的避免

查看锁信息（日志）

死锁

InnoDB的行锁模式及加锁方法

InnoDB

https://www.cnblogs.com/leedaily/p/8378779.html

7.锁

2. 事务

1.类型

B+tree

2.实现

1，较频繁的作为查询条件的字段应该创建索引；

4，不会出现在WHERE 子句中的字段不该创建索引；

索引的创建原则

3.创建

MyISAM索引文件和数据文件是分离的(非聚集)

InnoDB索引实现(聚集)

4.聚集索引和非聚集索引分别是什么意思，有什么区别

3.索引

1、每一列只能有一个值

2、每一行可以被唯一的区分

3、不包含其他表的已包含的非关键信息

垂直分库的做法，把一个数据库按照业务拆分成不同的数据库：

2.垂直分库

把单张表的数据按照一定的规则分布到多个数据库

3.水平分表

4.数据分片规则

分库分表

JOIN的原理

1.Explain:可以让我们查看MYSQL执行一条SQL所选择的执行计划

2.Profiling:可以用来准确定位一条SQL的性能瓶颈；

执行计划与执行明细

打开慢日志开关

1.开启慢查询日志 slow query log

2.慢日志分析

统计慢查询

3.选择需要优化的SQL

1、任何SQL的优化，都从Explain语句开始；Explain语句能够得到数据库执行该SQL选择的执行计划；

2、首先明确需要的执行计划，再使用Explain检查；

3、使用profile明确SQL的问题和优化的结果；

4.Explain和Profile入手

思路

1、永远用小结果集驱动大的结果集

2、在索引中完成排序

3、使用最小Columns

4、使用最有效的过滤条件

5、避免复杂的JOIN和子查询

6.尽量避免大事务操作，提高系统并发能力。

7.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

8.关于排序

关于索引

索引

军规

原则

sql优化原则

4.性能优化

mysql

7.数据库

1.数据库自增长序列或字段

2.uuid

3.snowkeFlake

4.Zookeeper

5. MongoDB的ObjectId

1.利用redis的原子操作INCR和INCRBY来执行

2.可以利用redis的lua脚本执行功能，在每个节点上通过lua脚本生成唯一ID。

6.Redis

1.分布式ID

优点：简单

1 数据库的可用性和性能将直接影响分布式锁的可用性及性能，所以，数据库需要双机部署、数据同步、主备切换； 2、不具备可重入的特性 3、没有锁失效机制； 4、不具备阻塞锁特性

缺点：

1.基于数据库实现分布式锁

利用 Redis set key 时的一个 NX 参数可以保证在这个 key 不存在的情况下写入成功。并且再加上 EX 参数可以让该 key 在超时之后自动删除。两个命令(NX EX)一起执行

2.基于Redis实现分布式锁

排他锁

共享锁

3.基于Zookeeper实现分布式锁

2.分布式锁

1.session复制

2.Session Sticky 方式管理

3. 缓存集中式管理

3.分布式session

分支主题

注销

5.单点登录

1.ACID

2.CAP和BASE

3.TCC

4.基于消息的异步确保型

5.最大努力通知型

开源框架

6.分布式事物

缓存的工作原理：更快读写的存储介质+减少IO+减少CPU计算=性能优化。

由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

缓存雪崩

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

1）采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。（2）如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓存中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴！

缓存穿透解决方案

缓存穿透

缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级

memcache与redis

数据库与缓存数据一致性解决方案

7.分布式缓存

8.分布式

1.jvm性能优化

2.数据库性能优化

1.关闭AJP协议

2.3种运行模式，设置为nio模式

3.调节线程池参数