springboot 怎么启动的时候加载热点数据到Redis

问题：加载数据前数据库连接必须已经实例化。

InitializingBean 接口的afterPropertiesSet在创建对象后直接调用，

@PostConstruct优于afterPropertiesSet调用

实现ApplicationRunner接口或者CommandLineRunner 会在项目启动最后调用

注入需要的类，会在实例话当前类的时候实例化需要的类。

同类型使用@Order注解排序，编号越大优先级越低

@DependsOn注解

Mysql查询学科前三名

单表：
学科表，学生表，成绩表

待添加答案

答题技巧：

总：当前问题回答的是哪些具体点

分：以1，2，3，4，5的方式细分描述相关的知识点，如果有哪里不清楚，直接忽略

突出技术名称（概念，接口，类，关键方法）

1. IOC原理和实现

创建容器(beanFactory,DefaultListableBeanFactory)

设置参数（beanpostprocessor，Aware接口子类）

beandefination对象

beanFactoryPostProcessor拓展beanFactory（占位符，PlaceHolderConfigurSuppor，ConfigurationClassPostProcessor）

BeanPostProcessor注册功能，拓展bean对象

反射将BeanDefination转换成bean对象

初始化bean对象（填充，调用aware，调用beanpostprocessor---init---beanpostprocessor）

生成

销毁

--- 对IOC的整体理解和处理过程

2. IOC底层实现

反射，工厂，设计模式（只说会的），关键方法

createBeanFactory, getBean,doGetBean,doCreateBean,refresh

描述bean的生命周期

深究Spring中Bean的生命周期

springbean lifecycle.jpg

实例化bean：反射

填充属性：populateBean()，【循环依赖，3级缓存】

调用aware接口的相关方法：invokeAwareMethod（完成BeanName，BeanFactory，BeanClassLoader对象得到属性设置）

调用BeanPostProcessor中的前置处理(ApplicationConterxtPostProcessor，设置ApplicationContext,Environment,ResourceLoader,EmbeddValueResolver等对象)

调用init-method方法：invokeInitMethod，判断是否实现了initializingBean接口，如果有，调用afterPropertiesSet方法

调用BeanPostprocessor的后置处理方法：spring的aop在此处实现（wrapIfNecessary()），AbstractAutoProxyCreator。注册Destuction相关的回调接口：钩子

获取完整对象，可以通过getBean获取

销毁，是否实现了DispoableBean接口，调用destroyMethod方法

循环依赖

三级缓存，提前暴露对象，aop

A依赖B，B依赖A 闭环

实例化，初始化（填充属性）

注入未完整初始化但已实例化对象的引用；（提前暴露）。

不同状态的对象存储在不同的缓存中。

一级缓存：完整对象

二级缓存：不完整对象

最终一级缓存中存在的话，删除二级缓存的相同名称对象。

三级缓存？三级缓存的value是个ObjectFactory，是个函数式接口,保证整个容器的运行过程中同名的bean只有一个。

所有的bean对象在创建的时候都要放入三级缓存中，在后续使用中，如果需要被代理返回代理，如果不需要，返回普通对象。

三级缓存：createBeanInstance之后

二级缓存：第一次从三级缓存确定对象是代理对象还是普通对象的时候，同时删除三级缓存；

一级缓存：生成完整对象，删除1，2级缓存。

spring如何解决循环依赖

Bean Factory 和FactoryBean的区别

相同：都是创建对象

不同：beanFactory创建对象必须遵循严格的生命周期流程，复杂；

如果需要简单自定义，并且交由spring管理，则需要实现FactoryBean接口：（简化版）

isSingleton：

getObjectType：

getObject：

spring中的设计模式

准备几个即可

单例

AOP

工厂

模板方法(PostProcessBeanFactory,onRefresh,initPropertyValue)

策略模式(配置文件解析)

观察者

适配器：Adapter

AOP实现原理

aop是ioc的拓展功能；

总：aop概念，动态代理

分：创建bean的过程对bean进行拓展，BeanPostProcessor

切面，切点

jdk或者cglib来生成

DynamicAdvisoredInterceptor类的intercept方法执行

事务是如何回滚的

aop执行中的TransactionInterceptor实现

分：解析方法上面的相关事务属性。

    关闭提交功能，开启事务

    执行逻辑

    执行失败，通过completeTransactionAfterThrowing来完成事务回滚操作，回滚方法：doRollBack()；

    执行成功，通过completeTransactionAfterReturning来完成，doCommit();

    执行完毕，清除相关的事务信息cleanupTranctionInfo

事务传播

跨线程传输和上下文传播

在分布式链路跟踪系统中，同一条请求处理链路要用一个全局唯一的 traceId 来标识，那就需要把 traceId 传输到该请求涉及的各个系统中。Trace 信息要在系统之间传输时，是通过各种 RPC 中间件里埋点，把 Trace 信息放在 HTTP Header、RPC Context 里进行传输的。

实际中，同一个系统内部业务处理出现多线程操作时，如果不做显式处理，也容易丢失 Trace 信息。那么遇到跨线程操作时，怎么做才能保证 Trace 信息不丢失呢？可以参考阿里开源的 transmittable-thread-local，基本原理是在创建 Runnable 或 Callabke 的时候，把父线程的 Trace 数据存起来传递给子线程，子线程执行之前先获取 Trace 数据设置 Context，再执行业务代码。

跨线程、跨系统传输 Trace 数据，如果只是用来串起调用链路，那就有点大材小用了，还可以用来做什么事儿呢？在[美团全链路压测]里，提到了：

对于单服务来说，识别压测流量很容易，只要在请求头中加个特殊的压测标识即可，HTTP 和 RPC 服务是一样的。但是，要在整条完整的调用链路中要始终保持压测标识，这件事就非常困难。
对于跨服务的调用，架构团队对所有涉及到的中间件进行了一一改造。利用 Mtrace（公司内部统一的分布式会话跟踪系统）的服务间传递上下文特性，在原有传输上下文的基础上，添加了测试标识的属性，以保证传输中始终带着测试标识。

快速对多个系统的数据库某个敏感字段加密

mybatis拦截器

如何设计一个配置中心 pull和push如何选择

规模，流量，负载

静态内置锁如何标记的

Class对象

nacos和Eureka

待添加答案

@FeignClient

name：指定FeignClient的名称，如果项目使用了Ribbon，name属性会作为微服务的名称，用于服务发现
url: url一般用于调试，可以手动指定@FeignClient调用的地址
decode404:当发生http 404错误时，如果该字段位true，会调用decoder进行解码，否则抛出FeignException
configuration: Feign配置类，可以自定义Feign的Encoder、Decoder、LogLevel、Contract
fallback: 定义容错的处理类，当调用远程接口失败或超时时，会调用对应接口的容错逻辑，fallback指定的类必须实现@FeignClient标记的接口
fallbackFactory: 工厂类，用于生成fallback类示例，通过这个属性我们可以实现每个接口通用的容错逻辑，减少重复的代码
path: 定义当前FeignClient的统一前缀

Sentinel

arthas

Arthas

Mysql

JVM

spring 注入

spring

Eureka源码

EurekaClient 源码核心

Spring请求过程

基础类库架构

Spring 三级缓存执行流程

Spring三级缓存源代码执行流程图

Spring解决循环依赖示意图

Spring解决循环依赖

Spring 导图

Spring 源码解析

导图地址

HTTPS

Kafka如何保证消息不丢失

生产者丢失消息的情况

生产者(Producer) 调用send方法发送消息之后，消息可能因为网络问题并没有发送过去。

所以，我们不能默认在调用send方法发送消息之后消息消息发送成功了。为了确定消息是发送成功，我们要判断消息发送的结果。但是要注意的是 Kafka 生产者(Producer) 使用 send 方法发送消息实际上是异步的操作，我们可以通过 get()方法获取调用结果，但是这样也让它变为了同步操作，示例代码如下：

SendResult<String, Object> sendResult = kafkaTemplate.send(topic, o).get();
if (sendResult.getRecordMetadata() != null) {
  logger.info("生产者成功发送消息到" + sendResult.getProducerRecord().topic() + "-> " + sendRe
              sult.getProducerRecord().value().toString());
}

但是一般不推荐这么做！可以采用为其添加回调函数的形式，示例代码如下：

        ListenableFuture<SendResult<String, Object>> future = kafkaTemplate.send(topic, o);
        future.addCallback(result -> logger.info("生产者成功发送消息到topic:{} partition:{}的消息", result.getRecordMetadata().topic(), result.getRecordMetadata().partition()),
                ex -> logger.error("生产者发送消失败，原因：{}", ex.getMessage()));

如果消息发送失败的话，我们检查失败的原因之后重新发送即可！

另外这里推荐为 Producer 的retries（重试次数）设置一个比较合理的值，一般是 3 ，但是为了保证消息不丢失的话一般会设置比较大一点。设置完成之后，当出现网络问题之后能够自动重试消息发送，避免消息丢失。另外，建议还要设置重试间隔，因为间隔太小的话重试的效果就不明显了，网络波动一次你3次一下子就重试完了

消费者丢失消息的情况

我们知道消息在被追加到 Partition(分区)的时候都会分配一个特定的偏移量（offset）。偏移量（offset)表示 Consumer 当前消费到的 Partition(分区)的所在的位置。Kafka 通过偏移量（offset）可以保证消息在分区内的顺序性。

mianshi_22

当消费者拉取到了分区的某个消息之后，消费者会自动提交了 offset。自动提交的话会有一个问题，试想一下，当消费者刚拿到这个消息准备进行真正消费的时候，突然挂掉了，消息实际上并没有被消费，但是 offset 却被自动提交了。

解决办法也比较粗暴，我们手动关闭自动提交 offset，每次在真正消费完消息之后之后再自己手动提交 offset 。 但是，细心的朋友一定会发现，这样会带来消息被重新消费的问题。比如你刚刚消费完消息之后，还没提交 offset，结果自己挂掉了，那么这个消息理论上就会被消费两次。

Kafka 弄丢了消息

我们知道 Kafka 为分区（Partition）引入了多副本（Replica）机制。分区（Partition）中的多个副本之间会有一个叫做 leader 的家伙，其他副本称为 follower。我们发送的消息会被发送到 leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步。生产者和消费者只与 leader 副本交互。你可以理解为其他副本只是 leader 副本的拷贝，它们的存在只是为了保证消息存储的安全性。

试想一种情况：假如 leader 副本所在的 broker 突然挂掉，那么就要从 follower 副本重新选出一个 leader ，但是 leader 的数据还有一些没有被 follower 副本的同步的话，就会造成消息丢失。

设置 acks = all

解决办法就是我们设置 acks = all。acks 是 Kafka 生产者(Producer) 很重要的一个参数。

acks 的默认值即为1，代表我们的消息被leader副本接收之后就算被成功发送。当我们配置 acks = all 代表则所有副本都要接收到该消息之后该消息才算真正成功被发送。

设置 replication.factor >= 3

为了保证 leader 副本能有 follower 副本能同步消息，我们一般会为 topic 设置 replication.factor >= 3。这样就可以保证每个分区(partition) 至少有 3 个副本。虽然造成了数据冗余，但是带来了数据的安全性。

设置 min.insync.replicas > 1

一般情况下我们还需要设置 min.insync.replicas> 1 ，这样配置代表消息至少要被写入到 2 个副本才算是被成功发送。min.insync.replicas 的默认值为 1 ，在实际生产中应尽量避免默认值 1。

但是，为了保证整个 Kafka 服务的高可用性，你需要确保 replication.factor > min.insync.replicas 。为什么呢？设想一下加入两者相等的话，只要是有一个副本挂掉，整个分区就无法正常工作了。这明显违反高可用性！一般推荐设置成 replication.factor = min.insync.replicas + 1。

设置 unclean.leader.election.enable = false

Kafka 0.11.0.0版本开始 unclean.leader.election.enable 参数的默认值由原来的true 改为false

我们最开始也说了我们发送的消息会被发送到 leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步。多个 follower 副本之间的消息同步情况不一样，当我们配置了 unclean.leader.election.enable = false 的话，当 leader 副本发生故障时就不会从 follower 副本中和 leader 同步程度达不到要求的副本中选择出 leader ，这样降低了消息丢失的可能性。

ThreadLocal原理

线程实例副本

防止内存泄漏

对于已经不再被使用且已被回收的 ThreadLocal 对象，它在每个线程内对应的实例由于被线程的 ThreadLocalMap 的 Entry 强引用，无法被回收，可能会造成内存泄漏。

针对该问题，ThreadLocalMap 的 set 方法中，通过 replaceStaleEntry 方法将所有键为 null 的 Entry 的值设置为 null，从而使得该值可被回收。另外，会在 rehash 方法中通过 expungeStaleEntry 方法将键和值为 null 的 Entry 设置为 null 从而使得该 Entry 可被回收。通过这种方式，ThreadLocal 可防止内存泄漏。

private void set(ThreadLocal<?> key, Object value) {
  Entry[] tab = table;
  int len = tab.length;
  int i = key.threadLocalHashCode & (len-1);

  for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) {
    ThreadLocal<?> k = e.get();
    if (k == key) {
      e.value = value;
      return;
    }
    if (k == null) {
      replaceStaleEntry(key, value, i);
      return;
    }
  }
  tab[i] = new Entry(key, value);
  int sz = ++size;
  if (!cleanSomeSlots(i, sz) && sz >= threshold)
    rehash();
}

适用场景

如上文所述，ThreadLocal 适用于如下两种场景

每个线程需要有自己单独的实例
实例需要在多个方法中共享，但不希望被多线程共享

对于第一点，每个线程拥有自己实例，实现它的方式很多。例如可以在线程内部构建一个单独的实例。ThreadLocal 可以以非常方便的形式满足该需求。

对于第二点，可以在满足第一点（每个线程有自己的实例）的条件下，通过方法间引用传递的形式实现。ThreadLocal 使得代码耦合度更低，且实现更优雅。

wait()方法为什么要放在Object类中

简单说：因为synchronized中的这把锁可以是任意对象，所以任意对象都可以调用wait()和notify()；所以wait和notify属于Object。

专业说：因为这些方法在操作同步线程时，都必须要标识它们操作线程的锁，只有同一个锁上的被等待线程，可以被同一个锁上的notify唤醒，不可以对不同锁中的线程进行唤醒。

也就是说，等待和唤醒必须是同一个锁。而锁可以是任意对象，所以可以被任意对象调用的方法是定义在object类中。

垃圾回收机制

垃圾回收算法是如何设计的

Java虚拟机详解—-垃圾收集器及GC参数

Java虚拟机详解—-GC算法和种类

一次线上内存溢出排查

既然CPU有缓存一致性协议（MESI），为什么JMM还需要volatile关键字？

通过提问的句式可以看出题主对于MESI和java的volatile的理解因果倒置 volatile是Java这种高级语言中的一个关键字,要实现这个volatile的功能,需要借助MESI!(请注意,这里只是说Java的volatile,而不涵盖C和C++的volatile)。

CPU有缓存一致性协议:MESI,这不错但MESI并非是无条件生效的!

不是说CPU支持MESI,那么你的变量就默认能做到缓存一致了。

根据MESI,CPU某核(假设CPU0)的缓存行(包含变量x)是M S 或E的时候,如果总线嗅探到了变量x被其其他核(比如CPU1)执行了写操作(remote write)那么CPU0中的该缓存行会置为I(无效),在CPU0后续对该变量执行读操作的时候,发现是I状态,就会去主存中同步最新的值(其实由于L3缓存的存在,这里也可能是直接从L3同步到CPU0的L1和L2缓存,而不直接访问主存)。

但实际可能不太理想,因为在CPU1执行写操作,要等到其他CPU(比如CPU0 CPU2 )将对应缓存行置为I状态,然后再将数据同步到主存,这个写操作才能完成由于这样性能较差所以引入了Store Buffer,CPU1只需要将数据写入到Store Buffer,而不等待其他CPU把缓存行状态置为I,就开始忙别的去了等到其他CPU通知CPU1我们都知道那个缓存失效啦,然后这个数据才同步到主存。

java虚拟机在实现volatile关键字的时候,是写入了一条lock 前缀的汇编指令。

lock 前缀的汇编指令会强制写入主存,也可避免前后指令的CPU重排序,并及时让其他核中的相应缓存行失效,从而利用MESI达到符合预期的效果。

非lock前缀的汇编指令在执行写操作的时候,可能是是不生效的比如前面所说的Store Buffer的存在,lock前缀的指令在功能上可以等价于内存屏障,可以让其立即刷入主存。

再来介绍一下何谓lock前缀指令 lock指令在汇编中不是单独出现的,而是作为前缀来修饰其他指令的可以和lock前缀修饰的指令有

ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG,DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, XCHG

比如：

lock addl $0×0, (%esp)

addl指令执行的时候会触发一个LOCK#信号,锁缓存(独占变量所在缓存行),指令执行完毕之后锁定解除注意addl $0 0, (%esp)是一个空操作,不会有任何影响,这里只是为了配合触发lock的效果。

是volatile的底层实现,满足了MESI的触发条件,才让变量有了缓存一致性所以孰因孰果。

一致性哈希和哈希槽

1、集群分片模式

如果 redis 只用复制功能做主从，那么当数据量巨大的情况下，单机情况下可能已经承受不下一份数据，更不用说是主从都要各自保存一份完整的数据。在这种情况下，数据分片是一个非常好的解决办法。

redis 的 custer 正是用于解决该问题。它主要提供两个功能：

1、自动对数据分片，落到各个节点上

2、即使集群部分节点失效或者连接不上，依然可以继续处理命令

对于第二点，它的功能有点类似于 sentienl 的故障转移，在这里不细说。下面详细了解下 redis 的槽位分片原理，在此之前，先了解下分布式简单哈希算法和一致性哈希算法，以帮助理解槽位的作用。

2、简单哈希算法

假设有三台机，数据落在哪台机的算法为：

c = Hash(key) % 3

例如 key A 的哈希值为4，4 % 3 = 1，则落在第二台机。Key ABC 哈希值为11，11 % 3 = 2，则落在第三台机上。

利用这样的算法，假设现在数据量太大了，需要增加一台机器。A 原本落在第二台上，现在根据算法4 % 4 = 0，落到了第一台机器上了，但是第一台机器上根本没有 A 的值。这样的算法会导致增加机器或减少机器的时候，引起大量的缓存穿透，造成雪崩。

3、一致性哈希算法

在1997年，麻省理工学院的 Karger 等人提出了一致性哈希算法，为的就是解决分布式缓存的问题。

在一致性哈希算法中，整个哈希空间是一个虚拟圆环。

mianshi_15

假设有四个节点 Node A、B、C、D，经过 ip 地址的哈希计算，它们的位置如下：

mianshi_16

有4个存储对象 Object A、B、C、D，经过对 Key 的哈希计算后，它们的位置如下：

mianshi_17

对于各个 Object，它所真正的存储位置是按顺时针找到的第一个存储节点。例如 Object A 顺时针找到的第一个节点是 Node A，所以 Node A 负责存储 Object A，Object B 存储在 Node B。

一致性哈希算法大概如此，那么它的容错性和扩展性如何呢？

假设 Node C 节点挂掉了，Object C 的存储丢失，那么它顺时针找到的最新节点是 Node D。也就是说 Node C 挂掉了，受影响仅仅包括 Node B 到 Node C 区间的数据，并且这些数据会转移到 Node D 进行存储。

mianshi_19

同理，假设现在数据量大了，需要增加一台节点 Node X。Node X 的位置在 Node B 到 Node C 直接，那么受到影响的仅仅是 Node B 到 Node X 间的数据，它们要重新落到 Node X 上。

所以一致性哈希算法对于容错性和扩展性有非常好的支持。但一致性哈希算法也有一个严重的问题，就是数据倾斜。

如果在分片的集群中，节点太少，并且分布不均，一致性哈希算法就会出现部分节点数据太多，部分节点数据太少。也就是说无法控制节点存储数据的分配。如下图，大部分数据都在 A 上了，B 的数据比较少。

mianshi_20

4、哈希槽

redis 集群（cluster）并没有选用上面一致性哈希，而是采用了哈希槽（slot）的这种概念。主要的原因就是上面所说的，一致性哈希算法对于数据分布、节点位置的控制并不是很友好。

首先哈希槽其实是两个概念，第一个是哈希算法。redis cluster 的 hash 算法不是简单的 hash()，而是 crc16 算法，一种校验算法。另外一个就是槽位的概念，空间分配的规则。其实哈希槽的本质和一致性哈希算法非常相似，不同点就是对于哈希空间的定义。一致性哈希的空间是一个圆环，节点分布是基于圆环的，无法很好的控制数据分布。而 redis cluster 的槽位空间是自定义分配的，类似于 windows 盘分区的概念。这种分区是可以自定义大小，自定义位置的。

redis cluster 包含了16384个哈希槽，每个 key 通过计算后都会落在具体一个槽位上，而这个槽位是属于哪个存储节点的，则由用户自己定义分配。例如机器硬盘小的，可以分配少一点槽位，硬盘大的可以分配多一点。如果节点硬盘都差不多则可以平均分配。所以哈希槽这种概念很好地解决了一致性哈希的弊端。

另外在容错性和扩展性上，表象与一致性哈希一样，都是对受影响的数据进行转移。而哈希槽本质上是对槽位的转移，把故障节点负责的槽位转移到其他正常的节点上。扩展节点也是一样，把其他节点上的槽位转移到新的节点上。

但一定要注意的是，对于槽位的转移和分派，redis 集群是不会自动进行的，而是需要人工配置的。所以 redis 集群的高可用是依赖于节点的主从复制与主从间的自动故障转移。

mianshi_21

RabbitMQ

1.RabbitMQ是什么？

RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，而群集和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。

2.RabbitMQ特点?

可靠性: RabbitMQ使用一些机制来保证可靠性，如持久化、传输确认及发布确认等。

灵活的路由 : 在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能， RabbitMQ 己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起，也可以通过插件机制来实现自己的交换器。

扩展性: 多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态地扩展集群中节点。

高可用性 : 队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队列仍然可用。

多种协议: RabbitMQ除了原生支持AMQP协议，还支持STOMP， MQTT等多种消息中间件协议。

多语言客户端 :RabbitMQ 几乎支持所有常用语言，比如 Java、 Python、 Ruby、 PHP、 C#、 JavaScript 等。

管理界面 : RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息、集群中的节点等。

令插件机制: RabbitMQ 提供了许多插件，以实现从多方面进行扩展，当然也可以编写自己的插件。

3.AMQP是什么?

RabbitMQ就是 AMQP 协议的 Erlang 的实现(当然 RabbitMQ 还支持 STOMP2、 MQTT3 等协议 ) AMQP 的模型架构和 RabbitMQ 的模型架构是一样的，生产者将消息发送给交换器，交换器和队列绑定。

RabbitMQ 中的交换器、交换器类型、队列、绑定、路由键等都是遵循的 AMQP 协议中相应的概念。目前 RabbitMQ 最新版本默认支持的是 AMQP 0-9-1。

4.AMQP协议3层？

Module Layer:协议最高层，主要定义了一些客户端调用的命令，客户端可以用这些命令实现自己的业务逻辑。

Session Layer:中间层，主要负责客户端命令发送给服务器，再将服务端应答返回客户端，提供可靠性同步机制和错误处理。

TransportLayer:最底层，主要传输二进制数据流，提供帧的处理、信道服用、错误检测和数据表示等。

5.AMQP模型的几大组件？

交换器 (Exchange)：消息代理服务器中用于把消息路由到队列的组件。
队列 (Queue)：用来存储消息的数据结构，位于硬盘或内存中。
绑定 (Binding)：一套规则，告知交换器消息应该将消息投递给哪个队列。

6.生产者Producer?

消息生产者，就是投递消息的一方。

消息一般包含两个部分：消息体（payload)和标签(Label)。

7.消费者Consumer?

消费消息，也就是接收消息的一方。

消费者连接到RabbitMQ服务器，并订阅到队列上。消费消息时只消费消息体，丢弃标签。

8.Broker服务节点？

Broker可以看做RabbitMQ的服务节点。一般请下一个Broker可以看做一个RabbitMQ服务器。

9.Queue队列？

Queue:RabbitMQ的内部对象，用于存储消息。多个消费者可以订阅同一队列，这时队列中的消息会被平摊（轮询）给多个消费者进行处理。

10.Exchange交换器？

Exchange:生产者将消息发送到交换器，有交换器将消息路由到一个或者多个队列中。当路由不到时，或返回给生产者或直接丢弃。

11.RoutingKey路由键？

生产者将消息发送给交换器的时候，会指定一个RoutingKey,用来指定这个消息的路由规则，这个RoutingKey需要与交换器类型和绑定键(BindingKey)联合使用才能最终生效。

12.Binding绑定？

通过绑定将交换器和队列关联起来，一般会指定一个BindingKey,这样RabbitMq就知道如何正确路由消息到队列了。

13.交换器4种类型？

主要有以下4种。

fanout:把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。

direct:把消息路由到BindingKey和RoutingKey完全匹配的队列中。

topic:

匹配规则：

RoutingKey 为一个点号'.': 分隔的字符串。比如: java.xiaoka.show

BindingKey和RoutingKey一样也是点号“.“分隔的字符串。

BindingKey可使用 和 # 用于做模糊匹配，匹配一个单词，#匹配多个或者0个

headers:不依赖路由键匹配规则路由消息。是根据发送消息内容中的headers属性进行匹配。性能差，基本用不到。

14.生产者消息运转？

1.Producer先连接到Broker,建立连接Connection,开启一个信道(Channel)。

2.Producer声明一个交换器并设置好相关属性。

3.Producer声明一个队列并设置好相关属性。

4.Producer通过路由键将交换器和队列绑定起来。

5.Producer发送消息到Broker,其中包含路由键、交换器等信息。

6.相应的交换器根据接收到的路由键查找匹配的队列。

7.如果找到，将消息存入对应的队列，如果没有找到，会根据生产者的配置丢弃或者退回给生产者。

8.关闭信道。

9.管理连接。

15.消费者接收消息过程？

1.Producer先连接到Broker,建立连接Connection,开启一个信道(Channel)。

2.向Broker请求消费响应的队列中消息，可能会设置响应的回调函数。

3.等待Broker回应并投递相应队列中的消息，接收消息。

4.消费者确认收到的消息,ack。

5.RabbitMq从队列中删除已经确定的消息。

6.关闭信道。

7.关闭连接。

16.交换器无法根据自身类型和路由键找到符合条件队列时，有哪些处理？

mandatory ：true 返回消息给生产者。

mandatory: false 直接丢弃。

17.死信队列？

DLX，全称为 Dead-Letter-Exchange，死信交换器，死信邮箱。当消息在一个队列中变成死信 (dead message) 之后，它能被重新被发送到另一个交换器中，这个交换器就是 DLX，绑定 DLX 的队列就称之为死信队列。

18.导致的死信的几种原因？

消息被拒（Basic.Reject /Basic.Nack) 且 requeue = false。
消息TTL过期。
队列满了，无法再添加。

19.延迟队列？

存储对应的延迟消息，指当消息被发送以后，并不想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费。

20.优先级队列？

优先级高的队列会先被消费。

可以通过x-max-priority参数来实现。

当消费速度大于生产速度且Broker没有堆积的情况下，优先级显得没有意义。

21.事务机制？

RabbitMQ 客户端中与事务机制相关的方法有三个:

channel.txSelect 用于将当前的信道设置成事务模式。

channel . txCommit 用于提交事务。

channel . txRollback 用于事务回滚,如果在事务提交执行之前由于 RabbitMQ 异常崩溃或者其他原因抛出异常,通过txRollback来回滚。

22.发送确认机制？

生产者把信道设置为confirm确认模式,设置后，所有再改信道发布的消息都会被指定一个唯一的ID，一旦消息被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认（Basic.Ack)给生产者（包含消息的唯一ID)，这样生产者就知道消息到达对应的目的地了。

23.消费者获取消息的方式？

24.消费者某些原因无法处理当前接受的消息如何来拒绝？

channel .basicNack
channel .basicReject

25.消息传输保证层级？

At most once:最多一次。消息可能会丢失，单不会重复传输。

At least once：最少一次。消息觉不会丢失，但可能会重复传输。

Exactly once: 恰好一次，每条消息肯定仅传输一次。

26.vhost?

每一个RabbitMQ服务器都能创建虚拟的消息服务器，也叫虚拟主机(virtual host)，简称vhost。

默认为“/”。

27.集群中的节点类型？

内存节点：ram,将变更写入内存。

磁盘节点：disc,磁盘写入操作。

RabbitMQ要求最少有一个磁盘节点。

28.队列结构？

通常由以下两部分组成？

rabbit_amqqueue_process :负责协议相关的消息处理，即接收生产者发布的消息、向消费者交付消息、处理消息的确认(包括生产端的 confirm 和消费端的 ack) 等。

backing_queue:是消息存储的具体形式和引擎，并向 rabbit amqqueue process 提供相关的接口以供调用。

29.RabbitMQ中消息可能有的几种状态?

alpha: 消息内容(包括消息体、属性和 headers) 和消息索引都存储在内存中。

beta: 消息内容保存在磁盘中，消息索引保存在内存中。

gamma: 消息内容保存在磁盘中，消息索引在磁盘和内存中都有。

delta: 消息内容和索引都在磁盘中。

HashMap 的负载因子

1. 什么是 loadFactor

首先我们来介绍下什么是负载因子（loadFactor），如果读者对这部分已经有了解，那么可以直接跨过这一段。

我们知道，第一次创建 HashMap 的时候，就会指定其容量（如果未明确指定，默认是 16），那随着我们不断的向 HashMap 中 put 元素的时候，就有可能会超过其容量，那么就需要有一个扩容机制。

所谓扩容，就是扩大 HashMap 的容量：

void addEntry(int hash, K key, V value, int bucketIndex) {
    if ((size >= threshold) && (null != table[bucketIndex])) {
        resize(2 * table.length);
        hash = (null != key) ? hash(key) : 0;
        bucketIndex = indexFor(hash, table.length);
    }
    createEntry(hash, key, value, bucketIndex);
}

从代码中我们可以看到，在向 HashMap 中添加元素过程中，如果 元素个数（size）超过临界值（threshold） 的时候，就会进行自动扩容（resize），并且，在扩容之后，还需要对 HashMap 中原有元素进行 rehash，即将原来桶中的元素重新分配到新的桶中。

在 HashMap 中，临界值（threshold） = 负载因子（loadFactor） * 容量（capacity）。

loadFactor 是装载因子，表示 HashMap 满的程度，默认值为 0.75f，也就是说默认情况下，当 HashMap 中元素个数达到了容量的 3/4 的时候就会进行自动扩容。

2. 为什么要扩容

还记得前面我们说过，HashMap 在扩容到过程中不仅要对其容量进行扩充，还需要进行 rehash！所以，这个过程其实是很耗时的，并且 Map 中元素越多越耗时。

rehash 的过程相当于对其中所有的元素重新做一遍 hash，重新计算要分配到那个桶中。

那么，有没有人想过一个问题，既然这么麻烦，为啥要扩容？HashMap 不是一个数组链表吗？不扩容的话，也是可以无限存储的呀。为啥要扩容？

这其实和哈希碰撞有关！！

哈希碰撞：

我们知道，HashMap 其实是底层基于哈希函数实现的，但是哈希函数都有如下一个基本特性：根据同一哈希函数计算出的哈希值如果不同，那么输入值肯定也不同。但是，根据同一哈希函数计算出的哈希值如果相同，输入值不一定相同。

两个不同的输入值，根据同一哈希函数计算出的哈希值相同的现象叫做碰撞。

衡量一个哈希函数的好坏的重要指标就是发生碰撞的概率以及发生碰撞的解决方案。

而为了解决哈希碰撞，有很多办法，其中比较常见的就是链地址法，这也是 HashMap 采用的方法。

HashMap 将数组和链表组合在一起，发挥了两者的优势，我们可以将其理解为链表的数组。

HashMap 基于链表的数组的数据结构实现的。

我们在向 HashMap 中 put 元素的时候，就需要先定位到是数组中的哪条链表，然后把这个元素挂在这个链表的后面。

当我们从 HashMap 中 get 元素的时候，也是需要定位到是数组中的哪条链表，然后再逐一遍历链表中的元素，直到查找到需要的元素为止。

但是，如果一个 HashMap 中冲突太高，那么数组的链表就会退化为链表。这时候查询速度会大大降低。

所以，为了保证 HashMap 的读取的速度，我们需要想办法尽量保证 HashMap 的冲突不要太高。

扩容避免哈希碰撞

那么如何能有效的避免哈希碰撞呢？

我们先反向思维一下，你认为什么情况会导致 HashMap 的哈希碰撞比较多？

无外乎两种情况：

1、容量太小。容量小，碰撞的概率就高了。狼多肉少，就会发生争抢。

2、hash 算法不够好。算法不合理，就可能都分到同一个或几个桶中。分配不均，也会发生争抢。

所以，解决 HashMap 中的哈希碰撞也是从这两方面入手。

这两点在 HashMap 中都有很好的体现。两种方法相结合，在合适的时候扩大数组容量，再通过一个合适的 hash 算法计算元素分配到哪个数组中，就可以大大的减少冲突的概率，就能避免查询效率低下的问题。

3. 为什么默认 loadFactor 是 0.75

解释了这么多，我们终于回归到了标题上的问题。

至此，我们知道了 loadFactor 是 HashMap 中的一个重要概念，他表示这个 HashMap 最大的满的程度。

为了避免哈希碰撞，HashMap 需要在合适的时候进行扩容。那就是当其中的元素个数达到临界值的时候，而这个临界值前面说过和 loadFactor 有关，换句话说，设置一个合理的 loadFactor，可以有效的避免哈希冲突。

那么，到底 loadFactor 设置成多少算合适呢？

这个值现在在 JDK 的源码中是 0.75：

/**
 * The load factor used when none specified in constructor.
 */
static final float DEFAULT_LOAD_FACTOR = 0.75f;

那么，为什么选择 0.75 呢？背后有什么考虑？为什么不是 1，不是 0.8？不是 0.5，而是 0.75 呢？

在 JDK 的官方文档中，有这样一段描述描述：

As a general rule, the default load factor (.75) offers a good tradeoff 
between time and space costs. Higher values decrease the space overhead 
but increase the lookup cost (reflected in most of the operations of the 
HashMap class, including get and put).

大概意思是：一般来说，默认的负载因子 (0.75) 在时间和空间成本之间提供了很好的权衡。更高的值减少了空间开销，但增加了查找成本(反映在 HashMap 类的大多数操作中，包括 get 和 put)。

试想一下，如果我们把负载因子设置成 1，容量使用默认初始值 16，那么表示一个 HashMap 需要在 "满了" 之后才会进行扩容。

那么在 HashMap 中，最好的情况是这 16 个元素通过 hash 算法之后分别落到了 16 个不同的桶中，否则就必然发生哈希碰撞。而且随着元素越多，哈希碰撞的概率越大，查找速度也会越低。

4. 0.75 的数学依据和必然性

理论上我们认为负载因子不能太大，不然会导致大量的哈希冲突，也不能太小，那样会浪费空间。

通过一个数学推理 log(2)/log(s/(s - 1)) ，当 s 趋于无穷大时，如果增加的键的数量使 P(0) = 0.5，那么 n/s 很快趋近于 log(2)，测算出这个数值在 log(2)（即：0.7 左右）时是比较合理的。

当然，这个数学计算方法，并不是在 Java 的官方文档中体现的，而是查询了一些资料习得，所以也无从考证，只做参考了。

那么，为什么最终选定了 0.75 呢？

还记得前面我们提到过一个公式吗，就是：临界值（threshold） = 负载因子（loadFactor） \* 容量（capacity）。

根据 HashMap 的扩容机制，它会保证 capacity 的值永远都是 2 的幂；

那么，为了保证负载因子（loadFactor） * 容量（capacity）的结果是一个整数，这个值是 0.75(3/4) 比较合理，因为这个数和任何 2 的幂乘积结果都是整数。

5. 总结（非常重要）

HashMap 是一种 K-V 结构，为了提升其查询及插入的速度，底层采用了链表的数组这种数据结构实现的。

但是因为在计算元素所在的位置的时候，需要使用 hash 算法，而 HashMap 采用的 hash 算法就是链地址法。这种方法有两个极端。

如果 HashMap 中哈希冲突概率高，那么 HashMap 就会退化成链表（不是真的退化，而是操作上像是直接操作链表），而我们知道，链表最大的缺点就是查询速度比较慢，他需要从表头开始逐一遍历。

所以，为了避免 HashMap 发生大量的哈希冲突，所以需要在适当的时候对其进行扩容。

而扩容的条件是元素个数达到临界值时。

HashMap 中临界值的计算方法：

临界值（threshold） = 负载因子（loadFactor） * 容量（capacity）

其中负载因子表示一个数组可以达到的最大的满的程度。这个值不宜太大，也不宜太小。

loadFactor 太大，比如等于 1，那么就会有很高的哈希冲突的概率，会大大降低查询速度。

loadFactor 太小，比如等于 0.5，那么频繁扩容没，就会大大浪费空间。

所以，这个值需要介于 0.5 和 1 之间。根据数学公式推算。这个值在 log(2) 的时候比较合理。

另外，为了提升扩容效率，HashMap 的容量（capacity）有一个固定的要求，那就是一定是 2 的幂。

所以，如果 loadFactor 是 3/4 的话，那么和 capacity 的乘积结果就可以是一个整数。

最后，一般情况下，我们不建议修改 loadFactor 的值，除非特殊原因。

nginx 限流配置

限流算法

令牌桶算法

算法思想是：

令牌以固定速率产生，并缓存到令牌桶中；
令牌桶放满时，多余的令牌被丢弃；
请求要消耗等比例的令牌才能被处理；
令牌不够时，请求被缓存。

漏桶算法

算法思想是：

水（请求）从上方倒入水桶，从水桶下方流出（被处理）；
来不及流出的水存在水桶中（缓冲），以固定速率流出；
水桶满后水溢出（丢弃）。
这个算法的核心是：缓存请求、匀速处理、多余的请求直接丢弃。
相比漏桶算法，令牌桶算法不同之处在于它不但有一只“桶”，还有个队列，这个桶是用来存放令牌的，队列才是用来存放请求的。

从作用上来说，漏桶和令牌桶算法最明显的区别就是是否允许突发流量(burst)的处理，漏桶算法能够强行限制数据的实时传输（处理）速率，对突发流量不做额外处理；而令牌桶算法能够在限制数据的平均传输速率的同时允许某种程度的突发传输。

Nginx按请求速率限速模块使用的是漏桶算法，即能够强行保证请求的实时处理速度不会超过设置的阈值。

Nginx官方版本限制IP的连接和并发分别有两个模块：

limit_req_zone 用来限制单位时间内的请求数，即速率限制,采用的漏桶算法 "leaky bucket"。
limit_req_conn 用来限制同一时间连接数，即并发限制。

limit_req_zone 参数配置

Syntax: limit_req zone=name [burst=number] [nodelay];
Default:    —
Context:    http, server, location
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

第一个参数：$binary_remote_addr 表示通过remoteaddr这个标识来做限制，“binary”的目的是缩写内存占用量，是限制同一客户端ip地址。
第二个参数：zone=one:10m表示生成一个大小为10M，名字为one的内存区域，用来存储访问的频次信息。
第三个参数：rate=1r/s表示允许相同标识的客户端的访问频次，这里限制的是每秒1次，还可以有比如30r/m的。

limit_req zone=one burst=5 nodelay;

第一个参数：zone=one 设置使用哪个配置区域来做限制，与上面limit_req_zone 里的name对应。
第二个参数：burst=5，重点说明一下这个配置，burst爆发的意思，这个配置的意思是设置一个大小为5的缓冲区当有大量请求（爆发）过来时，超过了访问频次限制的请求可以先放到这个缓冲区内。
第三个参数：nodelay，如果设置，超过访问频次而且缓冲区也满了的时候就会直接返回503，如果没有设置，则所有请求会等待排队。

例子：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
    server {
        location /search/ {
            limit_req zone=one burst=5 nodelay;
        }
}

下面配置可以限制特定UA（比如搜索引擎）的访问：

limit_req_zone  $anti_spider  zone=one:10m   rate=10r/s;
limit_req zone=one burst=100 nodelay;
if ($http_user_agent ~* "googlebot|bingbot|Feedfetcher-Google") {
    set $anti_spider $http_user_agent;
}

其他参数

Syntax: limit_req_log_level info | notice | warn | error;
Default:    
limit_req_log_level error;
Context:    http, server, location

当服务器由于limit被限速或缓存时，配置写入日志。延迟的记录比拒绝的记录低一个级别。例子：limit_req_log_level notice延迟的的基本是info。

Syntax: limit_req_status code;
Default:    
limit_req_status 503;
Context:    http, server, location

设置拒绝请求的返回值。值只能设置 400 到 599 之间。

ngx_http_limit_conn_module 参数配置

这个模块用来限制单个IP的请求数。并非所有的连接都被计数。只有在服务器处理了请求并且已经读取了整个请求头时，连接才被计数。

Syntax: limit_conn zone number;
Default:    —
Context:    http, server, location
limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    location /download/ {
        limit_conn addr 1;
    }

一次只允许每个IP地址一个连接。

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;

server {
    ...
    limit_conn perip 10;
    limit_conn perserver 100;
}

可以配置多个limit_conn指令。例如，以上配置将限制每个客户端IP连接到服务器的数量，同时限制连接到虚拟服务器的总数。

Syntax: limit_conn_zone key zone=name:size;
Default:    —
Context:    http
limit_conn_zone $binary_remote_addr zone=addr:10m;

在这里，客户端IP地址作为关键。请注意，不是$ remote_addr，而是使用$ binary_remote_addr变量。 $ remote_addr变量的大小可以从7到15个字节不等。存储的状态在32位平台上占用32或64字节的内存，在64位平台上总是占用64字节。对于IPv4地址，$ binary_remote_addr变量的大小始终为4个字节，对于IPv6地址则为16个字节。存储状态在32位平台上始终占用32或64个字节，在64位平台上占用64个字节。一个兆字节的区域可以保持大约32000个32字节的状态或大约16000个64字节的状态。如果区域存储耗尽，服务器会将错误返回给所有其他请求。

Syntax: limit_conn_log_level info | notice | warn | error;
Default:    
limit_conn_log_level error;
Context:    http, server, location

当服务器限制连接数时，设置所需的日志记录级别。

Syntax: limit_conn_status code;
Default:    
limit_conn_status 503;
Context:    http, server, location

设置拒绝请求的返回值。

实战

实例一限制访问速率

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server { 
    location / { 
        limit_req zone=mylimit;
    }
}

上述规则限制了每个IP访问的速度为2r/s，并将该规则作用于根目录。如果单个IP在非常短的时间内并发发送多个请求，结果会怎样呢？
单个IP 10ms内发送6个请求

我们使用单个IP在10ms内发并发送了6个请求，只有1个成功，剩下的5个都被拒绝。我们设置的速度是2r/s，为什么只有1个成功呢，是不是Nginx限制错了？当然不是，是因为Nginx的限流统计是基于毫秒的，我们设置的速度是2r/s，转换一下就是500ms内单个IP只允许通过1个请求，从501ms开始才允许通过第二个请求。

实例二 burst缓存处理

我们看到，我们短时间内发送了大量请求，Nginx按照毫秒级精度统计，超出限制的请求直接拒绝。这在实际场景中未免过于苛刻，真实网络环境中请求到来不是匀速的，很可能有请求“突发”的情况，也就是“一股子一股子”的。Nginx考虑到了这种情况，可以通过burst关键字开启对突发请求的缓存处理，而不是直接拒绝。
来看我们的配置：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server { 
    location / { 
        limit_req zone=mylimit burst=4;
    }
}

我们加入了burst=4，意思是每个key(此处是每个IP)最多允许4个突发请求的到来。如果单个IP在10ms内发送6个请求，结果会怎样呢？
设置burst

相比实例一成功数增加了4个，这个我们设置的burst数目是一致的。具体处理流程是：1个请求被立即处理，4个请求被放到burst队列里，另外一个请求被拒绝。通过burst参数，我们使得Nginx限流具备了缓存处理突发流量的能力。

但是请注意：burst的作用是让多余的请求可以先放到队列里，慢慢处理。如果不加nodelay参数，队列里的请求不会立即处理，而是按照rate设置的速度，以毫秒级精确的速度慢慢处理。

实例三 nodelay降低排队时间

实例二中我们看到，通过设置burst参数，我们可以允许Nginx缓存处理一定程度的突发，多余的请求可以先放到队列里，慢慢处理，这起到了平滑流量的作用。但是如果队列设置的比较大，请求排队的时间就会比较长，用户角度看来就是RT变长了，这对用户很不友好。有什么解决办法呢？nodelay参数允许请求在排队的时候就立即被处理，也就是说只要请求能够进入burst队列，就会立即被后台worker处理，请注意，这意味着burst设置了nodelay时，系统瞬间的QPS可能会超过rate设置的阈值。nodelay参数要跟burst一起使用才有作用。

延续实例二的配置，我们加入nodelay选项：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server { 
    location / { 
        limit_req zone=mylimit burst=4 nodelay;
    }
}

单个IP 10ms内并发发送6个请求，结果如下：
设置burst和nodela

跟实例二相比，请求成功率没变化，但是总体耗时变短了。这怎么解释呢？实例二中，有4个请求被放到burst队列当中，工作进程每隔500ms(rate=2r/s)取一个请求进行处理，最后一个请求要排队2s才会被处理；实例三中，请求放入队列跟实例二是一样的，但不同的是，队列中的请求同时具有了被处理的资格，所以实例三中的5个请求可以说是同时开始被处理的，花费时间自然变短了。

但是请注意，虽然设置burst和nodelay能够降低突发请求的处理时间，但是长期来看并不会提高吞吐量的上限，长期吞吐量的上限是由rate决定的，因为nodelay只能保证burst的请求被立即处理，但Nginx会限制队列元素释放的速度，就像是限制了令牌桶中令牌产生的速度。

看到这里你可能会问，加入了nodelay参数之后的限速算法，到底算是哪一个“桶”，是漏桶算法还是令牌桶算法？当然还算是漏桶算法。考虑一种情况，令牌桶算法的token为耗尽时会怎么做呢？由于它有一个请求队列，所以会把接下来的请求缓存下来，缓存多少受限于队列大小。但此时缓存这些请求还有意义吗？如果server已经过载，缓存队列越来越长，RT越来越高，即使过了很久请求被处理了，对用户来说也没什么价值了。所以当token不够用时，最明智的做法就是直接拒绝用户的请求，这就成了漏桶算法。

示例四自定义返回值

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server { 
    location / { 
        limit_req zone=mylimit burst=4 nodelay;
        limit_req_status 598;
    }
}

默认情况下没有配置 status 返回值的状态：

自定义 status 返回值的状态：
自定义返回值

JVM

Java8内存结构图

虚拟机内存与本地内存的区别

Java虚拟机在执行的时候会把管理的内存分配成不同的区域，这些区域被称为虚拟机内存，同时，对于虚拟机没有直接管理的物理内存，也有一定的利用，这些被利用却不在虚拟机内存数据区的内存，我们称它为本地内存，这两种内存有一定的区别：

JVM内存

受虚拟机内存大小的参数控制，当大小超过参数设置的大小时就会报OOM

本地内存

本地内存不受虚拟机内存参数的限制，只受物理内存容量的限制
虽然不受参数的限制，但是如果内存的占用超出物理内存的大小，同样也会报OOM

java运行时数据区域

java虚拟机在执行过程中会将所管理的内存划分为不同的区域，有的随着线程产生和消失，有的随着java进程产生和消失，根据《Java虚拟机规范》的规定，运行时数据区分为以下一个区域：

程序计数器（Program Counter Register）

程序计数器就是当前线程所执行的字节码的行号指示器，通过改变计数器的值，来选取下一行指令，通过他来实现跳转、循环、恢复线程等功能。

在任何时刻，一个处理器内核只能运行一个线程，多线程是通过线程轮流切换，分配时间来完成的，这就需要有一个标志来记住每个线程执行到了哪里，这里便需要到了程序计数器。
所以，程序计数器是线程私有的，每个线程都已自己的程序计数器。

虚拟机栈（JVM Stacks）

虚拟机栈是线程私有的，随线程生灭。虚拟机栈描述的是线程中的方法的内存模型：

每个方法被执行的时候，都会在虚拟机栈中同步创建一个栈帧（stack frame）。

每个栈帧的包含如下的内容

局部变量表
- 局部变量表中存储着方法里的java基本数据类型（byte/boolean/char/int/long/double/float/short）以及对象的引用（注：这里的基本数据类型指的是方法内的局部变量）
操作数栈
动态连接
方法返回地址

方法被执行时入栈，执行完后出栈

虚拟机栈可能会抛出两种异常：

如果线程请求的栈深度大于虚拟机所规定的栈深度，则会抛出StackOverFlowError即栈溢出
如果虚拟机的栈容量可以动态扩展，那么当虚拟机栈申请不到内存时会抛出OutOfMemoryError即OOM内存溢出

本地方法栈（Native Method Stacks）

本地方法栈与虚拟机栈的作用是相似的,都会抛出OutOfMemoryError和StackOverFlowError，都是线程私有的，主要的区别在于：

虚拟机栈执行的是java方法
本地方法栈执行的是native方法(什么是Native方法？)

Java堆（Java Heap）

java堆是JVM内存中最大的一块，由所有线程共享,是由垃圾收集器管理的内存区域，主要存放对象实例，当然由于java虚拟机的发展，堆中也多了许多东西，现在主要有：

对象实例
- 类初始化生成的对象
- 基本数据类型的数组也是对象实例
字符串常量池
- 字符串常量池原本存放于方法区，jdk7开始放置于堆中。
- 字符串常量池存储的是string对象的直接引用，而不是直接存放的对象，是一张string table
静态变量
- 静态变量是有static修饰的变量，jdk7时从方法区迁移至堆中
线程分配缓冲区（Thread Local Allocation Buffer）
- 线程私有，但是不影响java堆的共性
- 增加线程分配缓冲区是为了提升对象分配时的效率

java堆既可以是固定大小的，也可以是可扩展的（通过参数-Xmx和-Xms设定），如果堆无法扩展或者无法分配内存时也会报OOM。

方法区(Method Area)

方法区绝对是网上所有关于java内存结构文章争论的焦点，因为方法区的实现在java8做了一次大革新，现在我们来讨论一下：

方法区是所有线程共享的内存，在java8以前是放在JVM内存中的，由永久代实现，受JVM内存大小参数的限制，在java8中移除了永久代的内容，方法区由元空间(Meta Space)实现，并直接放到了本地内存中，不受JVM参数的限制（当然，如果物理内存被占满了，方法区也会报OOM），并且将原来放在方法区的字符串常量池和静态变量都转移到了Java堆中，方法区与其他区域不同的地方在于，方法区在编译期间和类加载完成后的内容有少许不同，不过总的来说分为这两部分：

类元信息（Klass）

类元信息在类编译期间放入方法区，里面放置了类的基本信息，包括类的版本、字段、方法、接口以及常量池表（Constant Pool Table）
常量池表（Constant Pool Table）存储了类在编译期间生成的字面量、符号引用(什么是字面量？什么是符号引用？)，这些信息在类加载完后会被解析到运行时常量池中

运行时常量池（Runtime Constant Pool）

运行时常量池主要存放在类加载后被解析的字面量与符号引用，但不止这些
运行时常量池具备动态性，可以添加数据，比较多的使用就是String类的intern()方法

直接内存

直接内存位于本地内存，不属于JVM内存，但是也会在物理内存耗尽的时候报OOM,所以也讲一下。

在jdk1.4中加入了NIO（New Input/Putput）类，引入了一种基于通道（channel）与缓冲区（buffer）的新IO方式，它可以使用native函数直接分配堆外内存，然后通过存储在java堆中的DirectByteBuffer对象作为这块内存的引用进行操作，这样可以在一些场景下大大提高IO性能，避免了在java堆和native堆来回复制数据。

常见问题

什么是Native方法？

由于java是一门高级语言，离硬件底层比较远，有时候无法操作底层的资源，于是，java添加了native关键字，被native关键字修饰的方法可以用其他语言重写，这样，我们就可以写一个本地方法，然后用C语言重写，这样来操作底层资源。当然，使用了native方法会导致系统的可移植性不高，这是需要注意的。

成员变量、局部变量、类变量分别存储在内存的什么地方？

类变量

类变量是用static修饰符修饰，定义在方法外的变量，随着java进程产生和销毁
在java8之前把静态变量存放于方法区，在java8时存放在堆中

成员变量

成员变量是定义在类中，但是没有static修饰符修饰的变量，随着类的实例产生和销毁，是类实例的一部分
由于是实例的一部分，在类初始化的时候，从运行时常量池取出直接引用或者值，与初始化的对象一起放入堆中

局部变量

局部变量是定义在类的方法中的变量
在所在方法被调用时放入虚拟机栈的栈帧中，方法执行结束后从虚拟机栈中弹出，所以存放在虚拟机栈中

由final修饰的常量存放在哪里？

final关键字并不影响在内存中的位置，具体位置请参考上一问题。

类常量池、运行时常量池、字符串常量池有什么关系？有什么区别？

类常量池与运行时常量池都存储在方法区，而字符串常量池在jdk7时就已经从方法区迁移到了java堆中。

在类编译过程中，会把类元信息放到方法区，类元信息的其中一部分便是类常量池，主要存放字面量和符号引用，而字面量的一部分便是文本字符，在类加载时将字面量和符号引用解析为直接引用存储在运行时常量池；

对于文本字符来说，它们会在解析时查找字符串常量池，查出这个文本字符对应的字符串对象的直接引用，将直接引用存储在运行时常量池；字符串常量池存储的是字符串对象的引用，而不是字符串本身。

什么是字面量？什么是符号引用？

字面量

java代码在编译过程中是无法构建引用的，字面量就是在编译时对于数据的一种表示:

int a=1;//这个1便是字面量
String b="iloveu";//iloveu便是字面量

符号引用

由于在编译过程中并不知道每个类的地址，因为可能这个类还没有加载，所以如果你在一个类中引用了另一个类，那么你完全无法知道他的内存地址，那怎么办，我们只能用他的类名作为符号引用，在类加载完后用这个符号引用去获取他的内存地址。

例子：我在com.demo.Solution类中引用了com.test.Quest，那么我会把com.test.Quest作为符号引用存到类常量池，等类加载完后，拿着这个引用去方法区找这个类的内存地址。

链路追踪实现原理

熔断与降级

Ribbon负载均衡原理

Redis实现分布式锁

Redis设计与实现

netty内存管理

ByteBuf 内部结构

UnpooledHeapByteBuf、UnpooledDirectByteBuf

源码分析Netty内存泄漏检测

Docker

docker笔记

docker查看启动命令

K8S

K8S网络

外网访问minikube内的pod

在 pod 中获取“ErrImageNeverPull”

浏览器

浏览器输入地址发生了什么

基础

IO模型

CDN 加速原理

说说Java泛型

微服务

SpringCloud gateway

配置文件的加载顺序以及优先级覆盖

文章版权归作者所有，未经允许请勿转载。

THE END

java
# java # 笔记 # 面试题

知识整理