shangjg3的博客

submitOrder()方法和updateProductStockCountById()方法都在OrderService类中，submitOrder()方法上没有标注事务注解，updateProductStockCountById()方法上标注了事务注解，submitOrder()方法调用了updateProductStockCountById()方法，此时，updateProductStockCountById()方法的事务在Spring中会失效。例如，如下代码所示。

在实例化 Bean 的过程中，Spring 容器会解析 Bean 之间的依赖关系，并将依赖的 Bean 注入到需要它们的 Bean 中。如果应用程序中使用了 AOP（面向切面编程），Spring 将会应用切面逻辑，为 Bean 动态生成代理，并将切面逻辑织入到相应的 Bean 中。Spring 容器会根据配置文件中的定义，实例化所有的 Bean。一旦所有的 Bean 实例化、依赖注入和初始化工作完成，Spring 容器就会完成启动过程，应用程序就可以开始处理请求和响应了。4）实例化 Bean。

这里有个值得注意的问题：从容器中获得proxy对象时应该是org.springframework.aop.framework.ProxyFactoryBean类型的对象(如下代码所示)，但这里直接就转换成IMath类型了，这是因为：ProxyFactoryBean本质上是一个用来生产Proxy的FactoryBean。如果容器中的某个对象持有某个FactoryBean的引用它取得的不是FactoryBean本身而是 FactoryBean的getObject()方法所返回的对象。即，它是类中的一个方法。

‌通过这种方式，‌Spring可以确保在需要时提供正确的对象实例，‌无论是原始对象还是其代理对象，‌从而解决了循环依赖的问题。：‌在某些情况下，‌二级缓存用于存储Bean的代理对象或原始实例，‌以避免重复创建。‌然而，‌在处理循环依赖时，‌二级缓存不足以解决问题，‌因为它不能确保在需要时总是提供正确的对象实例。‌当其他Bean依赖这个Bean时，‌可以直接从缓存中获取实例，‌避免重复创建。通过上面的图，仔细分析一下，其实把二级缓存拿掉，在 B 尝试获取 A 的时候直接返回 A 的实例，是不是也是可以的？

总的来说，过滤器是在 Servlet 容器层面上对请求进行处理的，而拦截器是在 Spring MVC 框架层面上对请求进行处理的，过滤器更加底层，可以对请求进行一些底层的处理，而拦截器更加高级，可以对请求进行一些业务逻辑层面的处理。这种方式可以将对象的创建和管理解耦，并且可以灵活地配置和管理对象。@Autowired是Spring提供的注解，而@Resource是JSR-250规范中定义的注解，因此@Autowired是Spring特有的注解，而@Resource是JavaEE的注解，它们的使用范围不同。

4、容器：Spring 框架提供了一个容器，用于管理应用程序的对象和依赖关系，并提供了一些可重用的核心组件，如 BeanFactory、ApplicationContext 等，这些对象可以是 Spring Bean、JDBC 连接、JMS 连接、Servlet 等。从而导致类与类之间的耦合度过高。AOP（Aspect Oriented Programming，面向切面编程）是 Spring 框架提供的一种重要机制，它可以将应用程序中的横切关注点（如日志、事务、安全等）从业务逻辑中分离出来，并集中管理。

参数：Object为由CGLib动态生成的代理类实例，Method为上文中实体类所调用的被代理的方法引用，Object[]为参数值列表，MethodProxy为生成的代理类对方法的代理引用。4.2、使用cglib完成动态代理，大概的原理是：cglib继承被代理的类，重写方法，织入通知，动态生成字节码并运行，因为是继承所以final类是没有办法动态代理的。5.4、如果项目中有多个类，则需要编写多个代理类，工作量大，不好修改，不好维护，不能应对变化。被代理的类必须实现接口，未实现接口则没办法完成动态代理。

它可以实现不用写代理类的实现就可以创建代理类对象；通过代理类对象执行目标接口中的方法，会把方法的调用分派给调用处理器（InvocationHandler）的实现类，执行实现类中的invoke()方法，我们需要把在该invoke()方法中实现调用目标类的目标方法；2.代理角色（连接真实角色的桥梁）：实现抽象角色，是真实角色的代理，通过真实角色的角色业务逻辑方法，来实现抽象方法，附加自己的操作。3.真实角色（需要被代理的对象）：实现抽象角色，定义真实的角色所要实现的业务逻辑，提供代理角色调用。

上面的代码中我们就是在@Before()中直接指定使用当前类定义的beforeAdd()方法对应的Pointcut的表达式，如果我们需要指定的Pointcut定义不是在当前类中的，我们需要加上类名称，如下面这个示例中引用的就是定义在MyService中的add()方法上的Pointcut的表达式。标准的Aspectj Aop的pointcut的表达式类型是很丰富的，但是Spring Aop只支持其中的9种，外加Spring Aop自己扩充的一种一共是10种类型的表达式，分别如下。

在创建Bean的过程中，Spring会使用三级缓存来管理对象的创建过程，保证在创建过程中依然能够提供已经初始化完成的对象引用，从而解决循环依赖的问题。Spring 解决循环依赖问题的核心在于提前暴露一个已经创建完成的对象引用，而不是提前暴露一个未初始化的代理对象。当请求Bean时，如果Bean正在创建中，则先返回一个临时的代理对象（早期代理对象），这样可以允许其他Bean引用该Bean，形成一个引用链。单例对象的创建过程中遇到循环依赖，Spring 采取提前暴露引用的方式解决。

众所周知，市面上存在很多工作流引擎，比如activiti、camunda、flowable等，但其功能基本都是大同小异，除了工作流本身的机制外，也会遵从标准的规范，下面就围绕工作流引擎重要的三大标准规范BPMN、CMMN、DMN展开介绍。随着用户审美需求的提高，简易的流程设计已经无法完全满足现代的可视化需求了，因此像钉钉，宜搭等也都构建了符合普通用户审美需求的工作流设计器，不过对于企业级地复杂流程还是建议采用符合BPMN2.0标准的流程设计器以设计更加复杂的流程场景。但是，如果数据没有流动，就没有工作流。

系统中引入规则引擎后，业务规则不再以程序代码的形式驻留在系统中，取而代之的是处理规则的规则引擎，业务规则存储在规则库中，完全独立于程序。drools是一款由JBoss组织提供的基于Java语言开发的开源规则引擎，可以将复杂且多变的业务规则从硬编码中解放出来，以规则脚本的形式存放在文件或特定的存储介质中(例如存放在数据库中)，使得业务规则的变更不需要修改项目代码、重启服务器就可以在线上环境立即生效。4、规则引擎是相对独立的，只关心业务规则，使得业务分析人员也可以参与编辑、维护系统的业务规则。

工作内存，drools规则引擎会从Working Memory中获取数据并和规则文件中定义的规则进行模式匹配，所以我们开发的应用程序只需要将我们的数据插入到Working Memory中即可，例如本案例中我们调用kieSession.insert(order)就是将order对象插入到了工作内存中。通过上面的入门案例我们可以发现，使用drools规则引擎主要工作就是编写规则文件，在规则文件中定义跟业务相关的业务规则，例如本案例定义的就是图书优惠规则。：执行引擎，执行Agenda中被激活的规则。

1.Drools基础语法1.1规则文件构成在使用Drools时非常重要的一个工作就是编写规则文件，通常规则文件的后缀为.drl。drl是DroolsRuleLanguage的缩写。在规则文件中编写具体的规则内容。一套完整的规则文件内容构成如下： 关键字 描述 package 包名，只限于逻辑上的管理，同一个包名下的查询或者函数可以直接调用 import 用于导入类

1、如果对象类型为包装类型时，在一个规则中改变了global的值，那么只针对当前规则有效，对其他规则中的global不会有影响。可以理解为它是当前规则代码中的global副本，规则内部修改不会影响全局的使用。前面我们已经知道了在规则体中的LHS部分是介于when和then之间的部分，主要用于模式匹配，只有匹配结果为true时，才会触发RHS部分的执行。两者的区别：当向Working Memory中加入多个满足条件的Fact对象时，使用了exists的规则执行一次，不使用exists的规则会执行多次。

第二步：创建规则目录/resources/rules，中rules目录中创建规则文件helloworld.drl。第四步：创建规则文件/resources/rules/helloworld.drl。第三步：创建规则文件/resources/rules/helloworld.drl。第一步：创建maven工程drools_springboot并配置pom.xml。第三步：创建Spring配置文件/resources/spring.xml。第三步：创建/resources/springmvc.xml文件。

进入es的安装根目录bin下，执行设置用户名和密码的命令,这里需要为4个用户分别设置密码，elastic,启动时，会动态生成文件，如果文件所属用户不匹配，会发生错误，需要重新进行修改用户和用户组。修改密码时，将第一步配置删除，然后重启es，将.security-7的索引删除即可。修改/etc/security/limits.d/20-nproc.conf。修改/etc/security/limits.conf。.yml文件，在里面添加如下内容,并重启es。修改/etc/sysctl.conf。

默认情况下，Elasticsearch中的每个索引被分片1个主分片和1个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有1个主分片和另外1个复制分片（1个完全拷贝），这样的话每个索引总共就有2个分片，我们需要根据索引需要确定分片个数。默认情况下，Elasticsearch中的每个索引被分片1个主分片和1个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有1个主分片和另外1个复制分片（1个完全拷贝），这样的话每个索引总共就有2个分片，我们需要根据索引需要确定分片个数。

这些都是映射里面可以设置的，其它就是处理ES里面数据的一些使用规则设置也叫做映射，按着最优规则处理数据对性能提高很大，因此才需要建立映射，并且需要思考如何建立映射才能对性能更好。比如：你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个订单的一个文档。为了找到相似的术语，fuzzy查询会在指定的编辑距离内创建一组搜索词的所有可能的变体或扩展。编辑距离是将一个术语转换为另一个术语所需的一个字符更改的次数。在进行关键字搜索时，搜索出的内容中的关键字会显示不同的颜色，称之为高亮。

1.

ElasticSearch文档分析 包含下面的过程：将一块文本分成适合于倒排索引的独立的 词条将这些词条统一化为标准格式以提高它们的“可搜索性”，或者 recall分析器执行上面的工作。分析器实际上是将三个功能封装到了一个包里字符过滤器首先，字符串按顺序通过每个 字符过滤器。他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉HTML，或者将 & 转化成 and。分词器其次，字符串被 分词器 分为单个的词条。一个简单的分词器遇到空格和标点的时候，可能会将文本拆分成词条。

Spring Data是一个用于简化数据库、非关系型数据库、索引库访问，并支持云服务的开源框架。其主要目标是使得对数据的访问变得方便快捷，并支持map-reduce框架和云计算数据服务。 Spring Data可以极大的简化JPA（Elasticsearch…）的写法，可以在几乎不用写实现的情况下，实现对数据的访问和操作。除了CRUD外，还包括如分页、排序等一些常用的功能。

Elasticsearch的基础是Lucene，所有的索引和文档数据是存储在本地的磁盘中，具体的路径可在ES的配置文件../config/elasticsearch.yml中配置，如下：

如果Eden区放不下这个对象，虚拟机会使用复制算法发生一次Minor GC，清除掉无用对象，同时将存活对象移动到Survivor的其中一个区(fromspace区或者tospace区)。发生MinorGC，对象会从Eden区进入Survivor区，如果Survivor区放不下从Eden区过来的对象时，此时会使用分配担保机制将对象直接移动到年老代。1.第一次Yong GC(Minor GC)后，Eden区还存活的对象复制到Surviver区的“To”区，“From”区还存活的对象也复制到“To”区，

动态对象年龄判定：（虚拟机并不会永远地要求对象的年龄都必须达到MaxTenuringThreshold才能晋升老年代，如果Survivor空间中相同年龄的所有对象的大小总和大于Survivor的一半，年龄大于或等于该年龄的对象就可以直接进入老年代），空间分配担保，老年代的连续空间大于（新生代所有对象的总大小或者历次晋升的平均大小）就会进行minor GC，否则会进行full GC。首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象，也可以反过来标记存活的对象，然后回收违背标记的对象。

CMS默认晋升老年代为6的原因： 简单来说，CMS对内存尤其敏感，且会导致单线程Serial FullGC 这个是非常严重的后果，而从结果上说越大的MaxTenuringThreshold会更快的导致heap的碎片化（不光old 区，首先要明白对于内存的分配并不是真的一个对象一个对象紧密排列的），所以历代CMS 默认这个值都会比较小（JDK8以前是4，之后调整为6）用户线程和垃圾收集线程同时执行（但并不一定是并行的，可能是交替执行的），垃圾收集线程在执行的时候不会停顿用户线程的运行。

并发转移阶段：在并发转移阶段，ZGC会将剩余的对象转移到新的ZPage中，并在转移后将新旧对象的地址对记录到转移映射表中。如果发现引用的对象已经完成了转移（例如，对象5已经转移到了新的位置），它会更新这个引用，使其指向对象5的新位置，并将remap标记为1，表示已经完成了重新映射。因此，在ZGC的并发转移阶段，通过用户线程和GC线程之间的智能协作，确保了垃圾收集过程的顺利进行和系统的高效运行。这种放弃不是简单的停止操作，而是GC线程的一种智能决策，它基于ZGC的并发转移策略和对系统状态的理解。

为了获得更好的 GC 表现，JDK 16 在支持就地搬移的同时，也支持预留（Reserve）堆内存的方式，并且 ZGC 不需要真的预留空闲的堆内存。默认情况下，只要有空闲的 region，ZGC 就会使用预留堆内存的方式，如果没有空闲的 region，否则 ZGC 就会启用就地搬移。不过就地搬移也有一定的挑战。● GC 标记线程访问对象时，如果对象地址视图是 Remapped，就把对象地址视图切换到 Marked0，如果对象地址视图已经是 Marked0，说明已经被其他标记线程访问过了，跳过不处理。

CMS收集器的垃圾收集算法采用的是标记-清除算法，这意味着每次执行完内存回收后，由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，不可避免地将会产生一些内存碎片。要保证用户线程能继续执行，前提的它运行的资源不受影响。重新标记（Remark)阶段：由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。

使用G1收集器时，它将整个Java堆划分成约2048个大小相同的独立Region块，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的N次幂，即1MB，2MB，4MB，8MB，16MB，32MB。内存的回收是以region作为基本单位的。HotSpot垃圾收集器里，除了G1以外，其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作，而G1 GC可以采用应用线程承担后台运行的GC工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。

上页提到的Remebered Set就是上述Reset，上页提到的Reference类型就是引用类型，其中Reset的作用是记录当前Region中哪些对象被外部引用指向，比如Old区中的对象会指向Eden区的对象，然后当我们要回收某个Region的时候，直接遍历当前Region中的所有对象就可以了，然后针对性的去找到那些指向当前对象的其他对象，最终确定当前对象是否是根可达的。如果垃圾占比太低，意味着存活的对象占比高，在复制的时候会花费更多的时间，则该region不会被回收。4、第四阶段，复制对象。

虽然 Thread 类提供了 `stop()` 方法，但其已经被标识为废弃，因为 `stop()` 只是暴力的停止线程， 但此时线程中的操作仍可能处于中间状态，此时暴力地停止就可能会产生非预期的结果。通常可以把一些不重要的线程设置为守护线程，比如监控其他线程状态的监控线程，当其他工作线程停止后，虚拟机就可以正常退出。在 Java 平台中，子线程的优先级默认与其父线程相同。线程中断与线程终止的区别在于：线程中断只是告诉目标线程，我希望你停止运行，即设置标志位，而线程是否真的停止则是由其自行决定。

写缓冲器是处理器的私有部件，一个处理器的写缓冲器所存储的内容是不能被其他处理器所读取的，这就会导致一个更新即便已经发生并写入到写缓冲器，但是其他处理器上的线程读取到的还是旧值，从而导致可见性问题。同时为了保证单线下执行的正确性，处理器会将重排序指令的执行结果先写入到重排序缓冲器（ROB，Recorder Buffer）中，之后再按照这些指令被处理器读取的顺序提交到寄存器或者主内存中，因此虽然指令是乱序执行的，但结果却是顺序提交的，从而能够保证在单线程下的正确性。

Java 虚拟机在实现 monitorenter 字节码（申请锁）和 monitorexit 字节码（释放锁）时需要借助一个原子操作（CAS操作），这个操作是比较昂贵的，因此内部锁在每次被线程获取时，它都会将对应的线程记录为偏好线程（Biased Thread），之后此线程无论是再次申请该锁还是获取该锁，都无须借助原先昂贵的原子操作，从而减少了锁的申请与释放的开销。通常我们把被修饰的方法体和代码块称为临界区，需要注意的是必须保证多线程锁住的是同一个临界区，否则依然是线程不安全的。

为了支持多线程之间的协作，JDK 中提供了两个非常重要的方法：wait() 和 notify() ，这两个方法定义在 Object 类中，这意味着任何 Java 对象都可以调用者两个方法。当 object.notify() 方法被调用时，它就会从这个等待队列中随机唤醒一个线程。综上所述可以使用 wait() 和 notify() 配合内部锁 synchronized 可以实现线程间的等待与唤醒，如果你使用的是显示锁而不是内部锁，此时可以使用 Condition 来实现同样的效果。

上面线程池分类中的 newSingleThreadScheduledExecutor() 和 newScheduledThreadPool() 都可以用于创建支持定时任务的线程池，它们返回的都是 ScheduledExecutorService 接口的实例。newSingleThreadExecutor()： 该方法返回一个只有一个线程的线程池。若多个任务被提交到该线程池，则多余的任务会被保存在一个任务队列中，待线程空闲，按照先入先出的顺序被执行。如果所有线程均处于工作状态，则会创建新的线程来进行处理。

使用 Callable 接口的限制是：其只能使用线程池提交，而不能使用单独的线程进行提交。此时通过 ExecutorService.submit() 进行提交，得到的是一个 Future 对象，它包含了线程的执行结果，当你调用其 get() 方法时，它会阻塞直至获取到线程的返回结果。ThreadLocal 是以增加资源的方式来避免竞态，它会为每一个线程创建一份私有的资源，从而避免对公共资源的竞争。1.3.4 组合多个 CompletableFuture。1. 多线程的返回对象-1.3.1 等待唤醒。

假设有如下场景，对于共享变量count，初始值为0，我们需要对它进行递增或者递减操作，但是在进行操作时，需要满足如下条件，进行递增时，count的值不能大于等于10，进行递减时，count的值需要大于0。通知完成后，T1线程会从条件变量的等待队列中出来，但是此时T1不会立马执行，而是需要重新进入到管程入口处的等待队列中。如下图的管程模型图中，方框代表管程对共享变量以及操作共享变量方法的封装，在入口处有一个等待队列，当有多个线程试图进入管程时，管程只允许一个线程进入，其他的线程进入到等待队列中。

此时假设我们设置的线程数量是 CPU 核心数的 2 倍，因为计算任务非常重，会占用大量的 CPU 资源，所以这时 CPU 的每个核心工作基本都是满负荷的，而我们又设置了过多的线程，每个线程都想去利用 CPU 资源来执行自己的任务，这就会造成不必要的上下文切换，此时线程数的增多并没有让性能提升，反而由于线程数量过多会导致性能下降。通过这个公式，我们可以计算出一个合理的线程数量，如果任务的平均等待时间长，线程数就随之增加，而如果平均工作时间长，也就是对于我们上面的 CPU 密集型任务，线程数就随之减少。

与 ArrayBlockingQueue 不同的是，LinkedBlockingQueue 使用链表而非数组来存储元素，因此它可以是一个有界队列也可以是一个无界队列。它是基于跳表（Skip List）的数据结构实现的，跳表是一种可以替代平衡树的数据结构，通过多层链表实现快速的查找、插入和删除操作。它基于数组实现，可以指定队列的容量。LinkedBlockingQueue 提供了一个灵活的阻塞队列实现，既可以配置为有界队列也可以是无界队列，适用于需要高并发处理的生产者-消费者场景、任务调度和数据缓冲等应用。