Java面试

妖狐艹你老母 2022-11-03 00:42 603阅读 0赞

1.JVM调优方法：https://blog.csdn.net/weixin\_40669549/article/details/104536114  
2.Java中线程池是如何实现的？ 创建线程池的几个核心构造参数是什么？  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70]  
其实java线程池的实现原理很简单，说白了就是一个线程集合workerSet和一个阻塞队列workQueue。当用户向线程池提交一个任务(也就是线程)时，线程池会先将任务放入workQueue中。workerSet中的线程会不断的从workQueue中获取线程然后执行。当workQueue中没有任务的时候，worker就会阻塞，直到队列中有任务了就取出来继续执行。

public ThreadPoolExecutor(int corePoolSize,
                                  int maximumPoolSize,
                                  long keepAliveTime,
                                  TimeUnit unit,
                                  BlockingQueue<Runnable> workQueue,
                                  ThreadFactory threadFactory,
                                  RejectedExecutionHandler handler)

corePoolSize: 规定线程池有几个线程(worker)在运行。  
maximumPoolSize: 当workQueue满了,不能添加任务的时候，这个参数才会生效。规定线程池最多只能有多少个线程(worker)在执行。  
keepAliveTime: 超出corePoolSize大小的那些线程的生存时间,这些线程如果长时间没有执行任务并且超过了keepAliveTime设定的时间，就会消亡。  
unit: 生存时间对于的单位  
workQueue: 存放任务的队列  
threadFactory: 创建线程的工厂  
handler: 当workQueue已经满了，并且线程池线程数已经达到maximumPoolSize，将执行拒绝策略。

3.Volatile和Synchronize的区别？  
1）volatile本质是在告诉jvm当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取； synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。  
2）volatile仅能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的  
3）volatile仅能实现变量的修改可见性，不能保证原子性；而synchronized则可以保证变量的修改可见性和原子性  
4）volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。  
5）volatile标记的变量不会被编译器优化；synchronized标记的变量可以被编译器优化

4.GC的机制是什么？  
**GC是什么**：垃圾回收器  
**GC的内存区域**：程序计数器、虚拟机栈、本地方法栈都是随线程而生随线程而灭，栈帧随着方法的进入和退出做入栈和出栈操作，实现了自动的内存清理，因此，我们的内存垃圾回收主要集中于 java 堆和方法区中，在程序运行期间，这部分内存的分配和使用都是动态的  
**GC的对象**：  
引用计数和可达性分析  
（1）引用计数：每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收。此方法简单，无法解决对象相互循环引用的问题。  
（2）可达性分析（Reachability Analysis）：从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。不可达对象。  
在Java语言中，GC Roots包括：  
虚拟机栈中引用的对象。  
方法区中类静态属性实体引用的对象。  
方法区中常量引用的对象。  
本地方法栈中JNI引用的对象。  
**什么时候触发**  
1）程序可以通过System.gc时可以触发  
2）系统自身决定GC触发时机  
GC又分为 minor GC 和 Full GC (也称为 Major GC )  
Minor GC触发条件：当Eden区满时，触发Minor GC。  
Full GC触发条件：  
a.调用System.gc时，系统建议执行Full GC，但是不必然执行  
b.老年代空间不足  
c.方法去空间不足  
d.通过Minor GC后进入老年代的平均大小大于老年代的可用内存  
e.由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小  
**GC做了什么事**  
主要做了清理对象，整理内存的工作。Java堆分为新生代和老年代，采用了不同的回收方式。（回收方式即回收算法详见后文）

是否可以立即回收内存？- 不行，由系统自己决定社么时候  
怎么样主动的通知JVM进行垃圾回收？ - System.gc时可以触发

5.类加载器双亲委派模型机制？  
当一个类收到了类加载请求时，不会自己先去加载这个类，而是将其委派给父类，由父类  
去加载，如果此时父类不能加载，反馈给子类，由子类去完成类的加载。

主要的类加载器  
**Bootstrap ClassLoader**(启动类加载器): 负责将%JAVA\_HOME%/lib目录中或-Xbootclasspath中参数指定的路径中的，并且是虚拟机识别的（按名称）类库加载到JVM中  
\*\*Extension ClassLoader（\*\*扩展类加载器): 负责加载%JAVA\_HOME%/lib/ext中的所有类库  
**Application ClassLoader**（应用程序加载器): 负责ClassPath中的类库

6.集合的种类和区别，HashMap底层如何实现(JDK1.8有所改动)，HashMap和ConcurrentHashMap的区别？  
集合的种类和区别  
Collection 及其子类  
List  
ArrayList  
LinkedList  
Vetory  
Set  
HashSet  
Queen  
Map及其子类  
HashMap  
LinedHashMap  
CurrentHashMp  
HashTable  
TreeTable  
HashMap1.8之前事数组加链表，1.8以后就是数组加链表加红黑树

区别  
hashmap 本质是数组+链表+红黑树，根据 key.hashcode( ) 计算出数组对应下标。如果多个 key 对应同一个下标，用一个链表串起来，新数据在前面。  
ConcurrentHashMap ：在 hashmap 基础上，ConcurrentHashMap 将数据分解成多个 segment (默认 16 个），每次操作对 segment 加锁，避免多线程锁的几率，提高并发效率。

7.Spring IOC如何管理Bean之间的依赖关系，怎么样避免循环依赖？  
Ioc通过注解（依赖注入），xml（配置bean信息）及硬编码的方式（new 一个对象那种）管理依赖关系。  
Bean实例化过程：先调用构造函数进行实例化，然后填充属性，再接着进行其他附加操作和初始化，当一个Bean调用构造函数进行实例化后，即使属性还未填充，就可以通过三级缓存向外暴露依赖的引用值（所以循环依赖问题的解决也是基于Java的引用传递），这也说明了另外一点，基于构造函数的注入，如果有循环依赖，Spring是不能够解决的。  
一级一级向下寻找，找出了前面提到的三级缓存，也就是三个Map集合类：  
singletonObjects：第一级缓存，里面放置的是实例化好的单例对象；  
earlySingletonObjects：第二级缓存，里面存放的是提前曝光的单例对象；  
singletonFactories：第三级缓存，里面存放的是要被实例化的对象的对象工厂。  
简单来说就是Bean在初始化的时候还没给属性赋值时就放在缓存里暴露了引用

8.SpringBean创建过程中的设计模式？  
工厂模式：BeanFactory、ApplicationContext  
单例模式：AbstractBeanFactory、DefaultSingletonBeanRegistry  
观察者模式：ApplicationEvent、ApplicationListener  
构建模式：BeanDefinitionBuilder  
原型模式：AbstractBeanFactory  
。。。。。。

9.InnoDB支持的四种事务隔离级别名称是什么？ 之间的区别是什么？  
Read Uncommitted（读取未提交内容） >> 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。  
Read Committed（读取提交内容） >> 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。  
Repeatable Read（可重读） >> 这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读（Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control 间隙锁）机制解决了该问题。注：其实多版本只是解决不可重复读问题，而加上间隙锁（也就是它这里所谓的并发控制）才解决了幻读问题。  
Serializable（可串行化） >> 这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。  
**区别：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70 1]  
1）.脏读。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据。  
2）.不重复读。解决了脏读后，会遇到，同一个事务执行过程中，另外一个事务提交了新数据，因此本事务先后两次读到的数据结果会不一致。  
3）.幻读。解决了不重复读，保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）。但是，如果另一个事务同时提交了新数据，本事务再更新时，就会“惊奇的”发现了这些新数据，貌似之前读到的数据是“鬼影”一样的幻觉。

10.聊一聊事务的特性  
ACID  
1.原子性 atomicity  
一个事物是一个不可分割的工作单位，其中的操作，要么都做，要么不做。不存在中间状态。  
2.一致性 consisitency  
事物执行的前后，数据必须处于一种合法的状态。（可以自己定义 ，保持数据的一致性。）  
3.隔离性 lsolation  
多个事物并发执行的时候，事物内部的操作与其他事物是隔离的，并发执行，互不干扰。  
4.持久性 Durability  
事物一旦提交，对数据库的改变是永久性的。不受任何影响。

11.什么是MySQL隔离级别？  
Read Uncommitted（读取未提交内容）  
Read Committed（读取提交内容）  
**Repeatable Read（可重读）Mysql默认**  
Serializable（可串行化）

11.如何理解BTree机制？（https://www.cnblogs.com/jshmztl/p/13204405.html）  
B树  
B-树又叫多路平衡查找树,是一种绝对平衡的树形结构.它的绝对平衡指的是所有的叶子节点数据都同一个水平线上  
总结：B-树的优势  
1）将磁盘IO的低效操作通过内存中数据比较进行替换.  
在二叉树中,一次只能加载一个关键字进行匹配.但是在B-树,一次可以加载N个关键字,若将磁盘块(节点)的空间大小固定(MySQL中定义为16KB).磁盘块能存储的关键字个数就会与单个关键字内容占用的空间相关.基于预读和操作系统磁盘交互特性.磁盘I/O一次加载的内容正好都是需要比对的内容.将内容的多次I/O加载转换成在内存中进行数据的比较.  
2）合理的降低树的高度,减少IO的次数.  
在树形结构中数据的所处高度位置,将带来IO的次数不一样.B-Tree结构合理的降低了树的高度.也就意味着数据的I/O次数将降低基于以上的特点,所以很多关系型数据库都采用B-Tree,或是B-Tree的变种数据结构作为索引的底层数据结构.

B+树  
B+树是基于B-树结构的加强版树形结构.  
B-树拥有的特性B+树都拥有.  
B+树的数据匹对规则采用闭合区间的方式  
B+树的非叶子节点上不保存关键字对应的数据区  
B+树的叶子节点上保存数据区  
在叶子节点上的数据产生形成首尾相连的链式结构带来更高效的数据排序

B+Tree相较于B-Tree的优势：  
B-树拥有的特性,B+树都拥有.  
B+树拥有更强劲的磁盘IO能力.在非叶子节点不存在数据区,将大大降低节点的空间占用.能存储  
更多的关键字.一次磁盘IO带回来的有效数据将更多更精准.  
B+树拥有更好的数据排序能力  
这是B+树的天然优势,在最末尾的叶子节点这一层天然即有序的链式结构.  
基于B+树的扫表能力更强  
在B+树的数据结构中,若需要扫表,只需要扫描最末尾的叶子节点即可.  
基于B+树结构的索引的查询,更趋于稳定  
在B-树结构中,我们发现,我们的关键字在某一个节点进行匹对成功就完成数据区内容的返回.但是在B+树结构中,我们采用的是闭合区间的比对方式即数据的最终加载一定会在叶子节点上.在B-树结构中,有可能针对一张表的查询,有些数据需要3次IO.有些只需要1次IO.前后的查询效率跌跌宕宕不稳定.但是在B+树结构中一定恒定的IO次数,带来更稳定的查询效率.

12.谈一谈对慢查询的分析？MySQL常用的优化方法有哪些？（https://www.cnblogs.com/yuanwanli/p/9024862.html）  
一般我们对慢查询语句进行优化，需要分析定位语句的执行情况，mysql的Explain命令可以很好的帮助我们，下边我们对Explain进行详解  
`Explain select * from notes where id = 137 ；//将Explain命令放到查询命令前即可`：  
![在这里插入图片描述][20210225223520159.png]  
索引没起作用的情况:  
　　(1) 使用LIKE关键字的查询语句  
在使用LIKE关键字进行查询的查询语句中，如果匹配字符串的第一个字符为“%”，索引不会起作用。只有“%”不在第一个位置索引才会起作用。  
　　(2)使用多列索引的查询语句  
MySQL可以为多个字段创建索引。一个索引最多可以包括16个字段。对于多列索引，只有查询条件使用了这些字段中的第一个字段时，索引才会被使用。  
　　(3)使用OR关键字的查询语句  
查询语句的查询条件中只有OR关键字，且OR前后的两个条件中的列都是索引时，查询中才会使用索引。否则，查询将不使用索引。  
优化数据库结构:  
合理的数据库结构不仅可以使数据库占用更小的磁盘空间，而且能够使查询速度更快。数据库结构的设计，需要考虑数据冗余、查询和更新的速度、字段的数据类型是否合理等多方面的内容。  
　　(1) 分解表

对于字段比较多的表，如果有些字段的使用频率很低，可以将这些字段分离出来形成新表。因为当一个表的数据量很大时，会由于使用频率低的字段的存在而变慢。

(2) 增加中间表  
对于需要经常联合查询的表，可以建立中间表以提高查询效率。通过建立中间表，把需要经常联合查询的数据插入到中间表中，然后将原来的联合查询改为对中间表的查询，以此来提高查询效率。

(3) 合理冗余字段  
设计数据库表时应尽量遵循范式理论的规约，尽可能减少冗余字段，让数据库设计看起来精致、优雅。但是合理加入冗余字段可以提高查询速度。  
　　  
　　(4) 切分查询  
比如我们要删除旧的数据，可能需要一次性删除很多数据会锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。将一个大的DELETE语句切成多个较小的查询可以尽可能小的影响MySQL性能，同时还可以减少MySQL复制的延迟，如下：  
DELETE FROM table WHERE create\_date < NOW();  
替换为  
rows\_affected = 0  
do \{  
rows\_affected = do\_query(  
“DELETE FROM table WHERE create\_date < NOW() LIMIT 10000”  
)  
\} while rows\_affected > 0  
一次删除一万行数据一般来说是一个比较高效而且对服务器影响也最小的做法，如果每次暂停一会会更好。

(5) 分解关联查询

将关联查询分解为多个小查询是很有必要的。就是可以对每一个表进行一次单表查询，然后将查询结果在应用程序中进行关联.例如：  
SELECT \* FROM tag  
JOIN tag\_post ON tag\_id = tag.id  
JOIN post ON tag\_post.post\_id = post.id  
WHERE tag.tag = ‘mysql’;  
分解为：  
SELECT \* FROM tag WHERE tag = ‘mysql’;  
SELECT \* FROM tag\_post WHERE tag\_id = 1234;  
SELECT \* FROM post WHERE post.id in (123,456,567);  
有很多场景都可以使用：比如当应用能够方便地缓存单个查询的结果的时候、当可以将数据分布到不同MySQL服务器上的时候、当能够使用IN()的方式代替关联查询的时候、当查询中使用同一个数据表的时候。

13.谈一谈悲观锁和乐观锁以及SQL的实现  
悲观锁和乐观锁，也并不是 MySQL 或者数据库中独有的概念，而是并发编程的基本概念。主要区别在于，操作共享数据时，“悲观锁”即认为数据出现冲突的可能性更大，而“乐观锁”则是认为大部分情况不会出现冲突，进而决定是否采取排他性措施。

反映到 MySQL 数据库应用开发中，悲观锁一般就是利用类似 SELECT … FOR UPDATE 这样的语句，对数据加锁，避免其他事务意外修改数据。乐观锁则与 Java 并发包中的 AtomicFieldUpdater 类似，也是利用 CAS 机制，并不会对数据加锁，而是通过对比数据的时间戳或者版本号，来实现乐观锁需要的版本判断。

14.简述三次握手和四次挥手的过程？  
三次握手  
A对B说：我的序号是x，我要向你请求连接；（第一次握手，发送SYN包，然后进入SYN-SEND状态）  
B听到之后对A说：我的序号是y，期待你下一句序号是x+1的话（意思就是收到了序号为x的话，即ack=x+1），同意建立连接。（第二次握手，发送ACK-SYN包，然后进入SYN-RCVD状态）  
A听到B说同意建立连接之后，对A说：与确认你同意与我连接（ack=y+1,ACK=1,seq=x+1）。（第三次握手，A已进入ESTABLISHED状态）  
B听到A的确认之后，也进入ESTABLISHED状态。

四次挥手  
1.A与B交谈结束之后，A要结束此次会话，对B说：我要关闭连接了（seq=u,FIN=1）。（第一次挥手，A进入FIN-WAIT-1）  
2.B收到A的消息后说：确认，你要关闭连接了。（seq=v,ack=u+1,ACK=1）（第二次挥手，B进入CLOSE-WAIT）  
3.A收到B的确认后,等了一段时间，因为B可能还有话要对他说。（此时A进入FIN-WAIT-2）  
4.B说完了他要说的话（只是可能还有话说）之后，对A说，我要关闭连接了。（seq=w, ack=u+1,FIN=1，ACK=1）(第三次挥手)  
5.A收到B要结束连接的消息后说：已收到你要关闭连接的消息。（seq=u+1,ack=w+1,ACK=1）(第四次挥手，然后A进入CLOSED)  
6.B收到A的确认后，也进入CLOSED。

15.B+树索引和Hash索引的区别？  
B+树是一个平衡的多叉树。B+树从根节点到叶子节点的搜索效率基本相当，不会出现大幅波动。  
哈希索引采用一定的哈希算法，把键值换成新的哈希值，检索时不需要类似B+树那样从根节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置。  
两者的区别：  
哈希索引的优势：  
（1）等值查询。哈希索引具有绝对优势（前提是：没有大量重复键值，如果大量重复键值时，哈希索引的效率很低，因为存在所谓的哈希碰撞问题。）  
哈希索引不适用的场景：  
（1）不支持范围查询  
（2）不支持索引完成排序  
（3）不支持联合索引的最左前缀匹配规则  
MySQL中，只有HEAP/MEMORY引擎才显示支持哈希索引。而常用的InnoDB引擎中默认使用的是B+树索引，它会实时监控表上索引的使用情况，如果认为建立哈希索引可以提高查询效率，则自动在内存中的“自适应哈希索引缓冲区”建立哈希索引（在InnoDB中默认开启自适应哈希索引），通过观察搜索模式，MySQL会利用index key的前缀建立哈希索引，如果一个表几乎大部分都在缓冲池中，那么建立一个哈希索引能够加快等值查询。

16.MySQL的锁并发（http://www.voidcn.com/article/p-fkchahov-bd.html）  
MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注：与MVCC相对的，  
是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。  
在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。  
在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，  
不用加锁。当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。  
在一个支持MVCC并发控制的系统中，哪些读操作是快照读？哪些操作又是当前读呢？以MySQL InnoDB为例：  
快照读：简单的select操作，属于快照读，不加锁。(当然，也有例外，下面会分析)  
**select \* from table where ?;**  
当前读：特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。  
**select \* from table where ? lock in share mode; select \* from table where ? for update; insert into table values (…); update table set ? where ?; delete from table where ?;**  
所有以上的语句，都属于当前读，读取记录的最新版本。并且，读取之后，还需要保证其他并发事务不能修改当前记录，对读取记录加锁。  
其中，除了第一条语句，对读取记录加S锁 (共享锁)外，其他的操作，都加的是X锁 (排它锁)。

17.高并发场景下如何防止死锁，保证数据的一致性  
采用乐观锁：  
对多个更新操作的业务加事物注解。在数据库表中加一个vesion版本控制字段（初始值为0)在更新操作前查询并记录该字段，更新操作完成vesion+1,再次查询vesion与更新操作前记录的值相差1说明前后数据一致，否则回滚更新操作

18.集群和负载均衡的算法与实现？  
负载均衡：  
轮询法：  
轮询算法按顺序把每个新的连接请求分配给下一个服务器，最终把所有请求平分给所有的服务器。既是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N(内部服务器个数)，然后重新开始循环。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。  
优点：绝对公平  
缺点：无法根据服务器性能去分配，无法合理利用服务器资源。  
加权轮询法：  
该算法中，每个机器接受的连接数量是按权重比例分配的。这是对普通轮询算法的改进，比如你可以设定：第三台机器的处理能力是第一台机器的两倍，那么负载均衡器会把两倍的连接数量分配给第3台机器。加权轮询分为：简单的轮询、平滑的轮询。  
什么是平滑的轮询，就是把每个不同的服务，平均分布。在Nginx源码中，实现了一种叫做平滑的加权轮询（smooth weighted round-robin balancing）的算法，它生成的序列更加均匀。5个请求现在分散开来，不再是连续的。  
随机法：  
负载均衡方法随机的把负载分配到各个可用的服务器上，通过随机数生成算法选取一个服务器。毕竟随机，，有效性受到了质疑。  
加权随机法：  
获取带有权重的随机数字，随机这种东西，不能看绝对，只能看相对。  
IP\_Hash算法：  
hash(object)%N算法，通过一种散列算法把请求分配到不同的服务器上。  
Source Hashing（源地址Hash）  
源地址散列调度算法是一种静态映射算法，它通过一个散列（Hash）函数将一个源IP地址映射到一台服务器，若该服务器是可用的并且没有超负荷，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址，所以这里不一个一个叙述。  
Destination hashing（目标地址Hash）  
目标地址散列调度算法也是针对目标IP地址的负载均衡，它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。  
Least-Connection（最少连接）  
最少连接调度算法是把新的连接请求分配到当前连接数最小的服务器，最小连接调度是一种动态调度短算法，它通过服务器当前所活跃的连接数来估计服务器的负载均衡，调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1，当连接中止或超时，其连接数减一，在系统实现时，我们也引入当服务器的权值为0时，表示该服务器不可用而不被调度。

19.简述分库与分表设计？  
**分表**  
上面场景中单表都几千万数据了，肯定扛不住。单表数据量太大，会极大影响sql 执行的性能，到了后面sql会很慢。一般来说，单表到几百万的时候，性能就会相对差一些了，就得分表。分表 就是把一个表的数据放到多个表中，然后查询的时候就查一个表。比如按照用户 id 来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在 200 万以内。  
**分库**  
一般，一个库最多支撑并发 2000，超过这个阈值一定要扩容的，而且一个健康的单库并发值建议保持在每秒 1000 左右，不要太大。我们可以将一个库的数据拆分到多个库中，访问的时候就访问一个库。

20.分库分表带来的分布式困境与对应之策有哪些？  
**数据迁移与扩容问题**  
前面介绍到水平分表策略归纳总结为随机分表和连续分表两种情况。连续分表有可能存在数据热点的问题，有些表可能会被频繁地查询从而造成较大压力，热数据的表就成为了整个库的瓶颈，而有些表可能存的是历史数据，很少需要被查询到。连续分表的另外一个好处在于比较容易，不需要考虑迁移旧的数据，只需要添加分表就可以自动扩容。随机分表的数据相对比较均匀，不容易出现热点和并发访问的瓶颈。但是，分表扩展需要迁移旧的数据。针对于水平分表的设计至关重要，需要评估中短期内业务的增长速度，对当前的数据量进行容量规划，综合成本因素，推算出大概需要多少分片。对于数据迁移的问题，一般做法是通过程序先读出数据，然后按照指定的分表策略再将数据写入到各个分表中。  
**表关联问题**  
在单库单表的情况下，联合查询是非常容易的。但是，随着分库与分表的演变，联合查询就遇到跨库关联和跨表关系问题。在设计之初就应该尽量避免联合查询，可以通过程序中进行拼装，或者通过反范式化设计进行规避。  
**分页与排序问题**  
一般情况下，列表分页时需要按照指定字段进行排序。在单库单表的情况下，分页和排序也是非常容易的。但是，随着分库与分表的演变，也会遇到跨库排序和跨表排序问题。为了最终结果的准确性，需要在不同的分表中将数据进行排序并返回，并将不同分表返回的结果集进行汇总和再次排序，最后再返回给用户。  
**分布式事务问题**  
随着分库与分表的演变，一定会遇到分布式事务问题，那么如何保证数据的一致性就成为一个必须面对的问题。目前，分布式事务并没有很好的解决方案，难以满足数据强一致性，一般情况下，使存储数据尽可能达到用户一致，保证系统经过一段较短的时间的自我恢复和修正，数据最终达到一致。  
**分布式全局唯一ID**  
在单库单表的情况下，直接使用数据库自增特性来生成主键ID，这样确实比较简单。在分库分表的环境中，数据分布在不同的分表上，不能再借助数据库自增长特性。需要使用全局唯一 ID，例如 UUID、GUID等。关于如何选择合适的全局唯一 ID，我会在后面的章节中进行介绍。  
总结  
分库与分表主要用于应对当前互联网常见的两个场景：海量数据和高并发。然而，分库与分表是一把双刃剑，虽然很好的应对海量数据和高并发对数据库的冲击和压力，但是却提高的系统的复杂度和维护成本。  
因此，我的建议：需要结合实际需求，不宜过度设计，在项目一开始不采用分库与分表设计，而是随着业务的增长，在无法继续优化的情况下，再考虑分库与分表提高系统的性能

21.加锁的机制是什么？  
https://blog.csdn.net/qq\_41181619/article/details/81407289  
公平锁/非公平锁  
可重入锁  
独享锁/共享锁  
互斥锁/读写锁  
乐观锁/悲观锁  
分段锁  
偏向锁/轻量级锁/重量级锁  
自旋锁

22.Redis和Setnx命令使如何实现分布式锁的？使用Redis怎么进行异步队列？会有什么缺点？  
setnx 大致原理，主要依托了它的 key 不存在才能 set 成功的特性，进程 A 拿到锁，在没有删除锁的 Key 时，进程 B 自然获取锁就失败了。如下图，也可以添加设置过期时间，过期了自动释放锁  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70 2]  
23.使用Redis怎么进行异步队列  
一般使用 list 结构作为队列，rpush 生产消息，lpop 消费消息。当 lpop 没有  
消息的时候，要适当 sleep 一会再重试  
**如果对方追问可不可以不用 sleep 呢？**  
list 还有个指令叫 blpop，在没有消息的时候，它会阻塞住直到消息到来。如果对  
方追问能不能生产一次消费多次呢？使用 pub/sub 主题订阅者模式，可以实现  
1:N 的消息队列。  
**如果对方追问 pub/sub 有什么缺点？**  
在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如 Kafka  
等。  
**如果对方追问 redis 如何实现延时队列？**  
我估计现在你很想把面试官一棒打死如果你手上有一根棒球棍的话，怎么问的这  
么详细。但是你很克制，然后神态自若的回答道：使用 sortedset，拿时间戳作为  
score，消息内容作为 key 调用 zadd 来生产消息，消费者用 zrangebyscore 指令  
获取 N 秒之前的数据轮询进行处理。到这里，面试官暗地里已经对你竖起了大拇  
指。但是他不知道的是此刻你却竖起了中指，在椅子背后。

24.treemap和HashMap的区别  
TreeMap：基于红黑树实现。TreeMap没有调优选项，因为该树总处于平衡状态。  
HashMap：基于哈希表实现。使用HashMap要求添加的键类明确定义了hashCode()和equals()\[可以重写hashCode()和equals()\]，为了优化HashMap空间的使用，您可以调优初始容量和负载因子。  
HashMap：适用于在Map中插入、删除和定位元素。  
Treemap：适用于按自然顺序或自定义顺序遍历键(key)。

25.多线程的五大状态？  
new对象时，线程创建 .  
start()线程进入就绪状态  
当获得cpu执行权时，开始执行run方法时为运行状态  
遇到 wait,sleep时，进入阻塞状态  
run方法执行完毕，线程进入死亡状态  
**创建，就绪，运行，阻塞，消亡**

26.MySQL主键和索引的区别？  
1、主键一定是唯一性du索zhi引，唯一性索引并不一定就是主键。  
2、一个表dao中可以有zhuan多个唯一性索引，但只能有一个主键。  
3、主键列不允许空值，而唯一性索引列允许空值。  
所谓主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。因为主键可以唯一标识某一行记录，所以可以确保执行数 据更新、删除的时 候不会出现张冠李戴的错误。主键除了上述作用外，常常与外键构成参照完整性约束，防止出现数据不一致。数据库在设计时，主键起到了很重要的作用。  
主键可以保证记录的唯一和主键域非空,数据库管理系统对于主键自动生成唯一索引，所以主键也是一个特殊的索引。

27.如何实现session共享？用Redis该如何实现？  
解决方案一：基于Nginx的ip\_hash 负载均衡  
其实就是对请求过来的ip地址对你的多少台可用的服务器进行取模，然后就会把你的请求通过Nginx的反向代理给分发到对应的服务器上。（这里会把可用的服务器放到一个数组中，如果取模得到的结果是几，就把请求分到服务器数组中的下标为几 的服务器上）  
解决方案二：基于Tomcat的session复制  
这个解决方案其实就是当用户请求的时候，把产生的sessionID给复制到系统所有的服务器中，这样就能保证当用户请求的时候从服务器A可能调用到服务器B上的模块的时候，也能保证服务B也有该用户的sessionID，这样就不会再次让用户进行再次登录操作了。也就解决问题了。  
解决方案三：使用Redis做缓存session的统一缓存  
这种方案呢，其实就是把每次用户的请求的时候生成的sessionID给放到Redis的服务器上。然后在基于Redis的特性进行设置一个失效时间的机制，这样就能保证用户在我们设置的Redis中的session失效时间内，都不需要进行再次登录。  
解决方案四：其实还可以把session放到cookie中去，因为每次用户请求的时候，都会把自己的cookie放到请求中，所以这样就能保证每次用户请求的时候都能保证用户在分布式环境下，也不会在进行二次登陆。

28.红黑树结构  
红黑树是特殊的平衡二叉树，平衡二叉树会自动会树进行旋转，保持树的平衡，但是每次插入都会进行旋转，效率低下，就有了红黑树  
红黑树如下四条规则：  
每个节点不是红色就是黑色的；  
根节点（顶端节点）总是黑色的；  
如果节点是红色的，则它的子节点必须是黑色的（反之不一定）；  
从根节点到叶节点或空子节点的每条路径，必须包含相同数目的黑色节点（即相同的黑色高度）。  
根据该规则，新插入的节点全都是红色，然后再根据具体情况做颜色变换甚至旋转。  
原因：如果我们新插入的颜色是黑色的话，那么每插入一个节点都会违背第四条规则，这样就导致每次都做变色甚至旋转。当插入红色节点时，首先不会违反第四条规则，并且如果其父节点是黑色时也不会违反第三条，至于第二条规则大部分情况不会违背基本不予以考虑了。这样一来插入红色就不是每次都需要变色或者旋转了，这样就可以优化计算机的处理过程。

29.JUC 线程安全， 怎样保障线程安全  
1互斥同步（阻塞同步）（悲观并发）  
互斥同步是最常见的一种并发正确性保障手段。同步是指在多线程并发访问共享数据时，保证共享数据在同一时刻只被一个线程使用（同一时刻，只有一个线程在操作共享数据）。而互斥是实现同步的一种手段，临界区、互斥量和信号量都是主要的互斥实现方式。因此，在这4个字里面，互斥是因，同步是果；互斥是方法，同步是目的。  
互斥同步的手段（方法）  
在java中，最基本的互斥同步手段就是synchronized关键字（就是同步方法和同步代码块），synchronized关键字编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码质量，这两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象。  
此外，ReentrantLock也是通过互斥来实现同步。在基本用法上，ReentrantLock与synchronized很相似，他们都具备一样的线程重入特性。（ReentrantLock使用起来就是“加锁lock()”和“解锁unlock()”）  
互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也成为阻塞同步。从处理问题的方式上说，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确地同步措施（例如加锁），那就肯定会出现问题，无论共享数据是否真的会出现竞争，它都要进行加锁。  
2非阻塞同步 （乐观并发）  
随着硬件指令集的发展，出现了基于冲突检测的乐观并发策略，通俗地说，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采用其他的补偿措施。（最常见的补偿错误就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步。  
乐观锁（乐观并发）需要操作和冲突检测这两个步骤具备原子性，这里就不能再使用互斥同步来保证了，只能靠硬件来完成。硬件支持的原子性操作最典型的是：比较并交换（Compare-and-Swap，CAS）。  
CAS指令需要有3个操作数，分别是内存地址（在java中理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和新值（用B表示）。CAS指令执行时，当且仅当V处的值符合旧预期值A时，处理器用B更新V处的值，否则它就不执行更新，但是无论是否更新了V处的值，都会返回V的旧值，上述的处理过程是一个原子操作。  
CAS缺点：  
ABA问题：因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。  
ABA问题的解决思路就是使用版本号。在变量前面追加版本号，每次变量更新的时候把版本号加一，那么A-B-A就变成了1A-2B-3C。JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

30.ThreadLocal的线程泄露问题(https://www.cnblogs.com/hi3254014978/p/13720147.html)  
原因：Thread(当前线程)持有Map<ThreadLocal, Object>，而Map对ThreadLocal的引用是弱引用，如果在线程中途ThreadLocal没有其它的强引用，那这个ThreadLocal对象随时会因为触发gc而被回收，被回收意味着这个ThreadLocal已经没有用了，即意味着这个ThreadLocal在这个线程对应的value也是没有用的，但，由于Map是当前线程持有，所以这个value不管有没有用（即不管ThreadLocal有没有被回收）都会一直存在直到线程被回收。这种情况下，如果使用了线程池，这个线程就一直不会回收，这里面对应的无用value将会一直占用内存，这种无意义的内存占用一直叠加就可能会内存泄露。  
解决：不过不用担心，ThreadLocal提供了这个问题的解决方案。  
每次操作set、get、remove操作时，会相应调用 ThreadLocalMap 的三个方法，ThreadLocalMap的三个方法在每次被调用时 都会直接或间接调用一个 expungeStaleEntry() 方法，这个方法会将key为null的 Entry 删除，从而避免内存泄漏。  
那么问题又来了，如果一个线程运行周期较长，而且将一个大对象放入LocalThreadMap后便不再调用set、get、remove方法仍然有可能key的弱引用被回收后，引用没有被回收，此时该仍然可能会导致内存泄漏。  
这个问题确实存在，没办法通过ThreadLocal解决，而是需要程序员在完成ThreadLocal的使用后要养成手动调用remove的习惯，从而避免内存泄漏。  
**既然弱引用会导致内存泄漏，那ThreadLocalMap为什么对ThreadLocal的引用要设置成弱引用？**  
为了尽快回收这个线程变量，因为这个线程变量可能使用场景不是特别多，所以希望使用完后能尽快被释放掉。因为线程拥有的资源越多，就越臃肿，线程切换的开销就越大，所以希望尽量降低线程拥有的资源量。

31.Bean的几种定义方式(https://www.cnblogs.com/wslook/p/9161560.html)  
1.基于XML的配置  
2.基于注解的配置  
3.基于Java类的配置

32.Mybatis如何防止SQL注入，是怎样实现的  
在编写MyBatis的映射语句时，尽量采用“\#\{xxx\}”这样的格式。若不得不使用“$\{xxx\}”这样的参数，要手工地做好过滤工作，来防止SQL注入攻击。  
\#\{\}：相当于JDBC中的PreparedStatement  
KaTeX parse error: Expected 'EOF', got '\#' at position 16: \{\}：是输出变量的值 简单说，\#̲\{\}是经过预编译的，是安全的；\{\}是未经过预编译的，仅仅是取变量的值，是非安全的，存在SQL注入。  
如果我们order by语句后用了$\{\}，那么不做任何处理的时候是存在SQL注入危险的。你说怎么防止，那我只能悲惨的告诉你，你得手动处理过滤一下输入的内容。如判断一下输入的参数的长度是否正常（注入语句一般很长），更精确的过滤则可以查询一下输入的参数是否在预期的参数集合中。

33,Redis如何保证数据一致性(https://blog.csdn.net/gly1256288307/article/details/88739612)  
方案：更新的时候，先删除缓存，然后再更新数据库。  
问题：在清除缓存后另外一个线程读取了数据，然后这个线程更新了，还是有脏数据  
升级方案：针对这种情况，可以先把“修改DB”的操作放到一个JVM队列，后面读请求过来之后，“更新缓存”的操作也放进同一个JVM队列,每个队列，对于一个作业线程，按照队列的顺序，依次执行相关操作，这样就可以保证“更新缓存”一定是在DB修改之后，以保证数据一致性

35.Kafka的角色

> 1）Producer ：消息生产者，就是向 kafka broker 发消息的客户端； 2）Consumer ：消息消费者，向  
> kafkabroker 取消息的客户端； 3）Consumer Group （CG）：消费者组，由多个 consumer  
> 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。  
> 4）Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个  
> topic。 5）Topic ：可以理解为一个队列，生产者和消费者面向的都是一个 topic；  
> 6）Partition：为了实现扩展性，一个非常大的 topic可以分布到多个 broker（即服务器）上， 一个 topic 可以分为多个  
> partition，每个 partition是一个有序的队列； 7）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的  
> partition 数据不丢失，且 kafka仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，  
> 一个 leader 和若干个 follower。 8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对  
> 象都是 leader。 9）follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据  
> 的同步。leader发生故障时，某个 follower 会成为新的 follower。

36.如果一个消费者在等待某个状态，导致消息一直卡着没消费，怎么办  
利用ack机制，手动修改偏移量（offset），如果卡主了就不改变偏移量值提交  
37.Mysql采用隔离级别，使用默认隔离级别要注意些什么  
默认是可重复读级别，会出现幻读，在查询的时候要避免插入数据，否则会出现幻读

38.HashMap和ConcurrentHashMap  
HashMap:低层采用数组+链表+红黑树  
ConcurrentHashMap:底层采用分段的数组+链表实现，线程安全  
通过把整个Map分为N个Segment，可以提供相同的线程安全，但是效率提升N倍，默认提升16倍。(读操作不加锁，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。)  
Hashtable的synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术  
有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁  
扩容：段内扩容（段内元素超过该段对应Entry数组长度的75%触发扩容，不会对整个Map进行扩容），插入前检测需不需要扩容，有效避免无效扩容

39.谈一谈Hash的一致算法  
https://www.cnblogs.com/lpfuture/p/5796398.html  
40.乐观锁和悲观锁  
**悲观锁**  
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。  
**乐观锁**  
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write\_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。  
**两种锁的使用场景**  
从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。  
**乐观锁常见的两种实现方式**  
乐观锁一般会使用版本号机制或CAS算法实现。

1.  版本号机制  
    一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功
2.  CAS算法  
    即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数  
    需要读写的内存值 V  
    进行比较的值 A  
    拟写入的新值 B  
    当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。  
    **乐观锁的缺点**  
    1.ABA 问题是乐观锁一个常见的问题  
    2 循环时间长开销大  
    3 只能保证一个共享变量的原子操作

41.可重入锁和Synchronized  
ReenTrantLock可重入锁（和synchronized的区别）总结  
可重入性：两者都是可重入的  
实现层面：synchronized关键字是基于jvm的，ReenTrantLock是基于jdk实现的。  
性能区别：JDK 5之后，synchronized引入了偏向锁，轻量级锁(自旋锁)后两者的性能相差不大。  
锁的粒度：synchronized关键字使用方便，但是对于粒度的控制不如可重入锁。  
ReentrantLock需要手动释放，如果忘记释放容易引起死锁，但是对于粒度控制强于synchronized关键字，ReentrantLock解决死锁的方法是对获取锁的等待时间进行设置并且可以获取各种锁的信息，以及灵活的实现多路通知。  
锁的实现机制上：sync操作Mark Word  
lock调用Unsafe类的park()方法  
**synchronized锁升级过程**  
偏向锁 -> 轻量级锁 -> 重量级锁  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70 3]  
**偏向锁**  
偏向锁就是指对象头中的 mark word 存储了当前线程的 ID；  
获取锁过程  
1.检查 mark word 中的线程 id 是不是当前线程，如果是当前线程，进入同步代码块；不是就执行步骤 2；  
2.进行 CAS 尝试将 线程 ID 换成自己；如果成功就执行代码块，不成功就执行步骤 3；  
3.当拥有锁的线程到达安全点之后，挂起这个线程，进行锁升级 - 步骤 4；  
4.锁升级，原持有偏向锁的线程，创建锁记录，将锁对象头拷贝到锁记录，唤醒持有锁的线程继续执行；然后释放轻量级锁 - 步骤 5  
5.1）对比对象头中的锁记录指针是否指向当前线程的锁记录； 2）对比线程锁记录中的 mark word 是否和对象头的 mark word 一致；如果一致就释放锁，不一致则执行步骤 6  
6.执行到这里，表示锁升级成重量级，释放锁，然后唤醒被挂起的线程。  
**锁消除**  
1.判断持有锁的线程是否处于同步块，如果处于就把 偏向锁 的升级为 轻量级锁；  
**轻量级锁**  
此时锁状态为轻量级锁  
1.当线程尝试获取锁时，会在栈中创建一个锁记录，并把锁对象的 mark word 拷贝到锁记录中；  
2.使用 CAS 尝试将锁对象的 mark word 更新为当前线程锁记录的指针，如果成功，表示持有锁，执行同步块，如果失败执行步骤 3  
3/线程就会自旋，重复步骤 2；如果达到一定次数，没有获取成功，就执行步骤 4  
4.锁升级，将线程锁对象头修改指向 monitor 的指针，然后继续执行代码块，释放重量级锁  
**自适应自旋**  
jvm 会根据上一次自旋的次数动态的调整自旋的次数，如果上一次自旋的次数少，表示线程自旋获取锁的概率大，jvm 会增加相应的次数，增加获取锁的概率，反之亦然；

42.事务的四大特性？  
事务包含原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。  
**原子性**：事务包含的所有操作要么全部成功，要么全部失败回滚；  
**一致性**：事务的执行结果必须是使数据库从一个一致性状态变到另一个一致性状态； eg: A向B转账(共有5000)，不管A和B之间如何转账，转几次账，事务结束后AB钱相加起来还得是5000；  
**隔离性**：数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离；  
**持久性**：事务一旦被提交，对数据库中数据的改变是永久性的，即便是在遇到故障的情况下也不会丢失提交事务的操作；

43.事务的二段提交机制？  
https://blog.csdn.net/zollty/article/details/111315800  
简单来说就是先预提交，没问题在全部提交

44.聚簇索引和非聚簇索引（https://www.cnblogs.com/jiawen010/p/11805241.html）  
**聚簇索引(聚集索引)**  
　　聚簇索引就是按照每张表的主键构造一颗B+树，同时叶子节点中存放的就是整张表的行记录数据，也将聚集索引的叶子节点称为数据页。这个特性决定了索引组织表中数据也是索引的一部分，每张表只能拥有一个聚簇索引。  
　　Innodb通过主键聚集数据，如果没有定义主键，innodb会选择非空的唯一索引代替。如果没有这样的索引，innodb会隐式的定义一个主键来作为聚簇索引。  
聚簇索引的优缺点  
　　优点：  
　　　　1.数据访问更快，因为聚簇索引将索引和数据保存在同一个B+树中，因此从聚簇索引中获取数据比非聚簇索引更快  
　　　　2.聚簇索引对于主键的排序查找和范围查找速度非常快  
　　缺点：  
　　　　1.插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于InnoDB表，我们一般都会定义一个自增的ID列为主键  
　　　　2.更新主键的代价很高，因为将会导致被更新的行移动。因此，对于InnoDB表，我们一般定义主键为不可更新。  
　　　　3.二级索引访问需要两次索引查找，第一次找到主键值，第二次根据主键值找到行数据。  
**辅助索引（非聚簇索引）**  
　　在聚簇索引之上创建的索引称之为辅助索引，辅助索引访问数据总是需要二次查找。辅助索引叶子节点存储的不再是行的物理位置，而是主键值。通过辅助索引首先找到的是主键值，再通过主键值找到数据行的数据页，再通过数据页中的Page Directory找到数据行。  
　　Innodb辅助索引的叶子节点并不包含行记录的全部数据，叶子节点除了包含键值外，还包含了相应行数据的聚簇索引键。  
　　辅助索引的存在不影响数据在聚簇索引中的组织，所以一张表可以有多个辅助索引。在innodb中有时也称辅助索引为二级索引。

45.举例说一下索引的应用场景和注意事项？  
应用场景：加快数据的查询  
注意事项：  
1.索引应该建在选择性高的字段上（键值唯一的记录数/总记录条数），选择性越高索引的效果越好、价值越大，唯一索引的选择性最高；  
2.组合索引中字段的顺序，选择性越高的字段排在最前面；  
3.where条件中包含两个选择性高的字段时，可以考虑分别创建索引，引擎会同时使用两个索引（在OR条件下，应该说必须分开建索引）；  
4.不要重复创建彼此有包含关系的索引，如index1(a,b,c) 、index2(a,b)、index3(a)；  
5.组合索引的字段不要过多，如果超过4个字段，一般需要考虑拆分成多个单列索引或更为简单的组合索引；

46.当前读和快照读  
快照读：简单的select是快照读。  
当前读：select for update，insert，update，delete 是当前读。  
原 理：在repeat read级别下，快照读是通过MVVC(多版本控制)和undo log来实现的，当前读是通过加record lock(记录锁)和gap lock(间隙锁)来实现的。

47.聊一聊类加载的过程？  
加载：根据查找路径找到相应的 class 文件然后导入；  
检查：检查加载的 class 文件的正确性；  
准备：给类中的静态变量分配内存空间；  
解析：虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为一个标示，而在直接引用直接指向内存中的地址；  
初始化：对静态变量和静态代码块执行初始化工作。

48.双亲委派机制及其使用原因？  
机制：将当前类的加载任务转给它的父类加载器，如果它的父类还有父类，就继续向上传递，如果父类加载器加载失败则自己加载。  
意义：避免重复加载以及核心类的修改风险。

49.聊一聊GC的算法？  
C/C++申请内存时都要malloc进行系统调用，使用完毕后通过free释放内存。Java虚拟机是先一次性分配一块较大的空间，然后在该空间上自动进行分配和释放，一般情况下程序员不需要手动操作。GC机制就是解决自动回收，面临三个问题：怎么确定垃圾，怎么回收垃圾，什么时候回收。  
**怎么确定垃圾：**  
引用计数算法:给对象添加一个引用计数器，当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是死亡的。引用计数算法很简单，判断效率也很高，但是JVM没有选用它来管理内存。原因是什么呢？主要是因为它很难解决循环引用的问题。  
可达性分析算法：通过一系列名为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所有走过的路径称为“引用链”，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。  
**怎么回收垃圾：**  
分代收集法：它根据对象的生存周期，将堆分为新生代和老年代。在新生代中，由于对象生存期短，每次回收都会有大量对象死去，那么这时就采用复制算法。老年代里的对象存活率较高，没有额外的空间进行分配担保，所以可以使用标记整理或者标记清除。  
标记清除法：将需要回收的对象标记出来，批量清除。缺点是效率低，产生碎片。  
标记整理法：将需要回收的对象标记出来，移动到一端再清除，避免了碎片的产生。  
复制法：将新生代内存划分为8:1:1三部分，较大的叫Eden区，其余是两块较小的Survior区。每次都会优先使用Eden区，若Eden区满，就将对象复制到第二块内存区上，然后清除Eden区，如果此时存活的对象太多，以至于Survivor不够时，会将这些对象通过分配担保机制复制到老年代中。  
**什么时候回收：**  
GC有两种类型：Scavenge GC和Full GC。

Scavenge GC：一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。  
Full GC：对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于Full GC的调节。有如下原因可能导致Full GC：  
年老代（Tenured）被写满  
持久代（Perm）被写  
System.gc()被显示调用  
上一次GC之后Heap的各域分配策略动态变化

50.Http和Https的区别？ 以及Https加密的方式  
**区别**  
HTTPS需要到CA申请证书, HTTP不需要  
HTTPS密文传输, HTTP明文传输  
连接方式不同, HTTPS默认使用443端口, HTTP使用80端口  
HTTPS=HTTP+加密+认证+完整性保护,较HTTP安全  
**加密方式**  
1.对称加密  
概念：对称密钥加密，又称为对称加密、私钥加密、共享秘钥加密，是密码学中的一类加密算法。这类算法在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。  
对称加密也可以理解为一方通过密钥将信息加密之后，把密文传给另一方，另一方通过这个相同的密钥将密文解密，转换成可以理解的明文。它们之间的关系如下：  
2.非对称加密  
概念：公开秘钥加密，也称为非对称加密，一种密码学算法类型，在这种密码学方法中，需要一对密钥，一个是私人密钥，另一个则是公开密钥。这两个密钥是数学相关，是某用户密钥加密后所得的信息，只能用该用户的解密密钥才能解密。如果知道了其中一个，并不能计算出另外一个。因此如果公开了一对密钥中的一个，并不会危害到另外一个的秘密性质。称公开的密钥为公钥，不公开的密钥为私钥。  
非对称加密的使用方式就是，比如A想将数据传输给B，那么首先A会向B索取一份公钥，A拿到公钥之后，通过该公钥对数据进行非对称加密，然后将密文传输给B，B收到密文之后通过私钥将其进行解密，从而得到数据内容。  
常见的非对称加密算法：RSA、Elgamal、背包算法、Rabin。  
RSA这种加密算法应用非常广泛，如SSH、HTTPS、TLS、电子证书、电子签名、电子身份证等。

51.线程池的核心参数和基本原理？线程池的调优策略  
**核心参数**  
corePoolSize：线程池里的线程数量，核心线程池大小  
maxPoolSize：线程池里的最大线程数量  
workQueue： 任务队列，用于存放提交但是尚未被执行的任务。  
keepAliveTime：当线程池中的线程数量大于 corePoolSize 时，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了 keepAliveTime 才会被回收销毁； 参数的时间单位为 unit。  
阻塞队列种类  
threadFactory：线程工厂，用于创建线程，一般可以用默认的  
handler：拒绝策略  
**原理（执行过程）**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70 4]  
**调优**  
要想合理的配置线程池，就必须首先分析任务特性，从以下几个角度来进行分析：  
任务的性质：CPU密集型任务，IO密集型任务和混合型任务。  
任务的优先级：高，中和低。  
任务的执行时间：长，中和短。  
任务的依赖性：是否依赖其他系统资源，如数据库连接。

52.Collections.sort底层的排序方式？  
1 Collection.sort（）排序通过泛型实现对所有类型的排序，对于基础类型，int等，按照数字大小排序，对于自定义对象类型，通过实现Comperable接口，重写compareto函数自定义比较大小的方式。接收对象类型为Comparable子类挥着Comparator外部比较器。  
2 Collections.sort()内部调用的Arrays.sort()方法，对于Arrays类，有两个sort()方法，sort(Object) (归并排序) sort(int) (快排)

53.排序的稳定性,以及不同场景下的排序策略  
？

54.Http请求过程，DNS解析的过程  
**Http请求过程**  
对网址进行DNS域名解析，得到对应的IP地址。  
根据IP找到对应的服务器，发起TCP的三次握手。  
建立TCP连接后发起HTTP请求。  
服务器响应HTTP请求，浏览器得到html代码。  
浏览器解析html代码，请求html中包含其他资源地址（如js、css图片等）。  
浏览器对页面进行渲染呈现给用户。  
**DNS解析的过程**  
查询本地hosts文件  
查询本次DNS缓存  
查询本地DNS服务器  
本地DNS服务器转发请求到根DNS服务器

55.三次握手和四次握手  
URG：紧急指针标志  
ACK：确认序号标志  
PSH：push标志  
RST：重置连接标志  
SYN （Synchronize Sequence Numbers） ：同步序列号，用于建立连接过程  
FIN：finish标志，用于释放链接  
**三次握手**  
第一次握手： 一开始都是close状态，客户端主动打开，服务端进入listen监听状态，等待请求，客户端发出连接请求报文（SYN包），报文头为SYN,seq为任意正整数x，此时进入同步发送状态（SYN\_SEND），等待服务器确认。 第二次握手： 如果服务端同意接收信息，会发出确认报文（SYN+ACK包 ），报文头seq为另外一个正整数y，ack为x+1，服务端进入同步收到的状态（SYN\_RCVD）； 前两步都不携带数据，都需要消耗一个序列号。 第三次握手： 客户端接收到确认报文（SYN+ACK包 ），进入ESTABLISHED状态，还要向服务端给出确认，发出确认报文（ACK包 ack=y+1 ），两端都进入ESTABLISHED状态，完成三次握手。 此后，双方就建立了链接，可以开始通信了。  
**四次挥手**  
第一次挥手： 最开始两方都处于ESTABLISHED状态，客户端主动关闭，发出连接释放报文（FIN）并且停止发送数据，报文头：FIN和seq =u（等于前面已经传送过来的数据的最后一个字节的序号加1），然后进入FINWAIT1状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。 第二次挥手： 服务器收到报文，发出确认报文（ACK，ack=u+1，序列号seq=v），进入CLOSEWAIT状态。 CLOSEWAIT状态：半关闭状态，服务器端不接收数据但可能还要发送数据。 第三次挥手： 客户端收到报文进入FINWAIT2状态，等待服务器发送第三次挥手，这段时间可以接收数据。服务端数据发送完后，会发送释放报文（FIN），但服务器很可能又发送了一些数据，序列号会变化，假定此时的序列号为seq=w ，此时进入LASTACK状态。 第四次挥手： 客户端收到报文后必须发送确认报文（ACK，ack=w+1，seq=u+1），进入TIMEWAIT，但连接没有释放，等待2MSL（2倍最大报文段寿命）来保证连接的可靠关闭才进入CLOSED状态。服务端收到确认直接进入CLOSED状态。

56.简述线程池和并发工具有哪些  
**线程池简介**  
线程池的核心逻辑是提前创建好若干个线程放在一个容器中。如果有任务需要处理，则将任务直接分配给线程池中的线程来执行就行，任务处理完以后这个线程不会被销毁，而是等待后续分配任务。同时通过线程池来重复管理线程还可以避免创建大量线程增加开销。  
**并发工具**  
1、CountDownLatch  
2、CyclicBarrier  
3、Semaphore  
4、Exchanger

57.数据库的索引和原理  
**索引**  
索引（Index）是帮助MySQL高效获取数据的数据结构。提取句子主干，就可以得到索引的本质：索引是数据结构。  
**原理**  
通过将关键数据组成有序的数据结构，提高用户的查询速度

58.频繁老年代回收怎么分析和解决？  
ps命令拿到pid：ps -ef|grep your\_application  
jstat命令查询gc情况：jstat -gcutil 172046 1000  
使用jmap分析对象占用内存情况，并导出到jmap.txt中： jmap -histo 172046 > jmap.txt

59.Spring IOC/AOP相关知识  
IOC是控制反转的意思，用于降低代码之间的耦合度。工厂模式的升华，可以把IOC容器看作是一个工厂，这个工厂里要生产的对象都在配置文件中给出定义，然后利用编程语言的的反射编程，根据配置文件中给出的类名生成相应的对象。 (对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来).  
AOP意为面向切面编程，基于代理思想。对原来目标对象创建代理对象，在不修改原对象代码情况下，通过代理对象增加增强功能的代码，从而对原有业务方法进行增强。实现方式有JDK动态代理和动态字节码Cglib技术。

61.阻塞队列不用Java提供的该怎么实现？  
https://blog.csdn.net/h525483481/article/details/80347485

62.负载均衡的原理？  
轮询  
将所有请求，依次分发到每台服务器上，适合服务器硬件相同的场景。  
优点：服务器请求数目相同  
缺点：服务器压力不一样，不适合服务器配置不同的情况  
随机  
请求随机分配到各台服务器上。  
优点：使用简单  
缺点：不适合机器配置不同的场景  
最少链接  
将请求分配到连接数最少的服务器上（目前处理请求最少的服务器）。  
优点：根据服务器当前的请求处理情况动态分配  
缺点：算法实现相对复杂，需要监控服务器请求连接数  
Hash（源地址散列）  
根据IP地址进行Hash计算，得到IP地址。  
优点：将来自同一IP地址的请求，同一会话期内，转发到相同的服务器，实现会话粘滞  
缺点：目标服务器宕机后，会话会丢失  
加权  
在轮询、随机、最少链接、Hash等算法的基础上，通过加权的方式，进行负载服务器分配。  
优点：根据权重，调节转发服务器的请求数目  
缺点：使用相对复杂

63.Redis的数据一致性问题，分布式多节点和单节点环境下分别描述  
https://blog.csdn.net/qq\_27384769/article/details/79499373

64.讲讲Docker容器  
Docker是一个容器化平台，它以容器的形式将您的应用程序及其所有依赖项打包在一起，以确保您的应用程序在任何环境中无缝运行。

65.如何实现高并发环境下的削峰、限流？  
66.什么情况下会造成雪崩？该怎么避免这种情况  
67.高并发架构的设计思路

参考：**https://www.cnblogs.com/xiaoyangjia/p/11393733.html**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70]: /images/20221024/9bb1f2e5bad74ccf981320f76b41e235.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70 1]: /images/20221024/4cffe2b742304ef5aa6731133b7d9d4e.png
[20210225223520159.png]: /images/20221024/0f1b3dc0662d47528e44b9cb32353e5a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70 2]: /images/20221024/f9dc906b5afc4e66ab3b5b1583ae121d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70 3]: /images/20221024/63444a86a8e143d89b884b96417e8698.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NTM3NzIy_size_16_color_FFFFFF_t_70 4]: /images/20221024/4b28f88ebed24765b19d0e279a3a9b28.png