weixin_42910501的博客

Spring AOP 中的动态代理主要有两种方式，JDK 动态代理和 CGLIB 动态代理。如果目标类没有实现接口，那么 Spring AOP 会选择使用 CGLIB 来动态代理目标类。（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成某个类。的子类，注意，CGLIB 是通过继承的方式做的动态代理，因此如果某个类被标记为 final，理通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口。那么它是无法使用CGLIB 做动态代理的。

之后继续做属性填充，这时候就发现引用到B，开始创建B，实例化之后暴露B，然后属性填充填充A,这个时候A并没有走完不在单例池里面，这个时候去走A的创建流程，这个给时候发现A已经提前暴露，先getBean，实例化，填充属性，初始化，代理：先调用提前处理，提前暴露，先把factory(A)放入三级缓存（调用提前处理方法），先把代理A放入单例池里；先尝试获取bean，到bean工厂，bean工厂到bean的仓库取，有就返回，没有就创建。验证完之后去单例池看看是否存在，是否提前暴露，没有就开始创建，存在就直接返回。

三阶段提交（Three-Phase Commit）：为了解决两阶段提交协议中的阻塞等待问题，三阶段提交协议引入了第三个阶段，即准备（Prepare）阶段。在提交阶段，协调者会向所有参与者发送提交请求，并等待它们的提交反馈。两阶段提交（Two-Phase Commit）：在两阶段提交协议中，涉及到多个参与者的事务首先进入预提交（Pre-Commit）阶段，然后进入提交（Commit）阶段。两阶段提交协议包括预提交和提交两个阶段，而三阶段提交协议包括准备、提交和回滚三个阶段。

通过 selector.select()阻塞轮询复路器上就绪的 channel 即可，也就是说，如果。这些都是 Linux 系统提供的 IO 复用机制的实现，其中 select 和 poll 是基于轮询。某个客户端连接数据传输完成，那么 select()方法会返回就绪的 channel，然后。IO 多路复用机制，核心思想是让单个线程去监视多个连接，一旦某个连接就绪，在 IO 多路复用机制的实现原理中，客户端请求到服务端后，此时客户端在传输。就通知应用程序，去获取这个就绪的连接进行读写操作。

Spring Boot 的自动装配机制的实现中，通过扫描约定路径下的 spring.factories。而在 Spring Boot 中，我们不需要再去做这些繁琐的配置，Spring Boot 已经自。个脚手架，通过 Spring Boot，我们可以快速开发基于 Spring 生态下的应用程序。Spring Boot 就是约定优于配置这一理念下的产物，它类似于 Spring 框架下的一。首先，约定优于配置是一种软件设计的范式，它的核心思想是减少软件开发人员。动帮我们完成了，这就是约定由于配置思想的体现。

Starter 是 Spring Boot 的四大核心功能特性之一，除此之外，Spring Boot 还有。Starter 内部集成了自动装配的机制，也就说在程序中依赖对应的 starter 组件以。在我看来，Starter组件几乎完美的体现了Spring Boot里面约定优于配置的理念。依赖 Starter 组件后，这个组件对应的功能所需要维护的外部化配置，会自动集。Starter 组件以功能为纬度，来维护对应的 jar 包的版本依赖，其中，Starter 是启动依赖，它的主要作用有几个。

其实，自动装配的思想，在 SpringFramework3.x 版本里面的@Enable 注解，就。自动装配，简单来说就是自动把第三方组件的 Bean 装载到 Spring IOC 器里面，这个配置类是放在第三方的 jar 包里面，然后通过 SpringBoot 中的约定优于配置。这样 SpringBoot 就可以知道第三方 jar 包里面的配置类的位置，这个步骤主要是。在我看来，SpringBoot 是约定优于配置这一理念下的产物，所以在很多的地方，它的出现，让开发人员更加聚焦在了业务代码的编写上，

assign：计算好的值重新赋值到工作内存 store 存储 工作内存数据写入主内存 write store的变量赋值给主内存的变量。如果不加volatile修饰 变量先从主存读取数据，读取后计算重新赋值，然后再在某个时刻将变量同步到主存，这时候会有总线嗅探机制，通过MESI缓存一致性协议让工作内存的变量失效。工作内存就会立即将数据同步到主存，会引起其他工作内存缓存的该内存地址失效MESI，提供内存屏障 ，在lock 之前不能指令重排序。工作内存是线程私有，主存共享的；内存有八大原子操作 包括。

2）这个配置类是放在第三方的jar包里面，然后通过Spring Boot中约定大于配置的理念，去把配置类的全路径放在件META_INF/Spring.factories文件里面，SpringBoot就可以知道第三方jar包里面配置类的位置，它主要是依靠Spring里面的SpringFactorierLoader来完成的。3）SpringBoot拿到所有第三方jar包声明的配置类之后，再通过ImportSelector这样一个接口来实现对这些配置类的动态加载，从而去完成自动装配这样的一个动作。

读取数据步骤：磁盘读取到内核缓冲区-》内核缓冲区通过线程上下文切换进行内核态切换到用户态，从内核缓冲区buffer写到用户态缓冲区buffer，然后需要发送到客户端，需要通过socket通信发送，socket也是内核态的，需要把用户态的数据写到socket的缓冲区（发送缓冲区）-》socket发送到网卡由网卡进行传输。磁头寻址步骤非常的耗时，而kafka进行的是append操作，parition是有序的，顺序读写节省了寻址时间，访问时间接近内存）；访问的时候要从用户态切换到内核态保证安全性；

消息系统都致力于让consumer以最大的速率最快速的消费消息，但不幸的是，push模式下，当 broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式。在这方面，Kafka遵循了一种大部分消息系统共同的传统的设计：producer将消息推送到broker，consumer从broker拉取消息。Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到t达。

自动提交：设置为enable.auto.commit为true，表示开启自动提交，自动提交会在每次调用poll时，提交上次poll时的消费位移，每次poll时，都是提交上次的offset的位移，如果是在单线程的情况，不会出现消费丢失的情况，但是对应多线程的应用来说，就有可能出现消费丢失的情况，例如我们每次poll到的数据都先放在一个队列中，用一个专门的线程来处理队列中的数据，但是我们poll的时候，上次提交的位移还没有完成消费，消费端出现了宕机，这个时候消费端重启后，就会出现消息丢失的情况。

首先，在 kafka 的架构里面，用到了 Partition 分区机制来实现消息的物理存储，生产者在发送消息的时候，会根据消息的 key 进行取模，来决定把当前消息存储。者是完全独立的网络节点，所有可能会出现，消息的消费顺序不是按照发送顺序。针对这个问题，一般的解决办法就是自定义消息分区路由的算法，然后把指定的。另外，有些设计方案里面，在消费端会采用异步线程的方式来消费数据来提高消。息的处理效率，那这种情况下，因为每个线程的消息处理效率是不同的，所以即。来实现的，从而导致乱序的问题。

Consumer 端会从分配的 Partition 里面去消费消息，如果 Consumer 在默认的 5。每消费一批数据，Kafka Broker 就会更新 OffSet 的值，避免重复消费。Kafka 消费端的自动提交逻辑有一个默认的 5 秒间隔，也就是说在 5 秒之后的下。首先，Kafka Broker 上存储的消息，都有一个 Offset 标记。默认情况下，消息消费完以后，会自动提交 Offset 的值，避免重复消费。缩短单个消息消费的市场。基于这样的背景下，我认为解决重复消费消息问题的方法有几个。

nacos结合两种模式，通过客户端每隔一段时间向服务端发送一次请求 10毫秒，请求时候在请求头上携带长轮询的超时时间，默认30s；服务端接收到客户端的请求时，会挂起一段时间，如果期间配置发生变化会立即响应到客户端。服务端控制响应客户端的请求响应时间。要么push服务端主动推送到客户端，时效性可以，但是服务端需要维持与客户端的心跳连接，比较消耗资源维持心跳；一旦发现和服务端的配置有差异，就表示服务端配置有更新，于是把更新的配置。在这个过程中，有可能因为客户端配置比较多，导致比较的时间较长，使得配置。

key=hobby 时，hash 计算得到的索引也是 1，这个就是 hash 冲突。再 hash 法，就是当通过某个 hash 函数计算的 key 存在冲突时，再用另外一个。链式寻址法，这是一种非常常见的方法，简单理解就是把存在 hash 冲突的 key，所谓 hash 冲突，是由于哈希算法被计算的数据是无限的，而计算后的结果范围。Hash 算法，就是把任意长度的输入，通过散列算法，变成固定长度的输出，这。开放定址法，也称为线性探测法，就是从发生冲突的那个位置开始，按照一定的。

Lock 锁的粒度是通过它里面提供的 lock()和 unlock()方法决定的，包裹在这两个。些区别，Synchronized 引入了偏向锁、轻量级锁、重量级锁以及锁升级的方式。Synchronized 由于是关键字，所以它无法实现非阻塞竞争锁的方法，另外，方法之间的代码能够保证线程安全性。Lock 提供了公平锁和非公平锁的机制，公平锁是指线程竞争锁资源时，如果已。期来控制锁的作用范围，比如锁对象是静态对象或者类对象，那么这个锁就是全。如果锁对象是普通实例对象，那这个锁的范围取决于这个实例的声明周期。

是 ConcurrentHashMap 在 HashMap 的基础上，提供了并发安全的实现。在 JDK1.8 中，ConcurrentHashMap 锁的粒度是数组中的某一个节点，而在。另外，随着 ConcurrentHashMap 的动态扩容，一旦链表长度小于 8，红黑树会。当数组长度不够时，ConcurrentHashMap 需要对数组进行扩容，在扩容的实现。JDK1.7，锁定的是 Segment，锁的范围要更大，因此性能上会更低。则直接从数组中随机选择一个，再通过 CAS 实现原子递增。

CPU 利用率较高的进程，在通过 Shift+H 找到进程中 CPU 消耗过高的线程，这。CPU 利用率过高的线程 id 不断变化，说明线程创建过多，需要挑选几个线程 id，CPU 利用率过高之后，导致应用中的线程无法获得 CPU 的调度，从而影响程序。CPU 利用率过高的线程一直是同一个，说明程序中存在线程长期占用 CPU 没有。个线程，如果有多个线程要执行，CPU 只能通过上下文切换的方式来执行不同。CPU 资源过度消耗，也就是在程序中创建了大量的线程，或者有线程一直占用。让处于等待中的线程执行。

因此，当通过 id>4 这样一种范围查询加锁时，会加 next-key Lock，锁定的区间。间隙锁和 next-key Lock 的区别在于加锁的范围，间隙锁只锁定两个索引之间的。next-key Lock 相当于间隙锁和记录锁的合集，记录锁锁定存在的记录行，间隙。引用间隙，而 next-key Lock 会锁定多个索引区间，它包含记录锁和间隙锁。所以，在 InnoDB 中设计了一种间隙锁，它的主要功能是锁定一段范围内的索引。锁锁住记录行之间的间隙，而 next-key Lock 锁住的是两者之和。