2.计算机访问内存的方式都是一次一个字节 3.一个引用（机器地址）需要8个字节表示： 例如： Date date = new Date(),则date这个变量需要占用8个字节来表示 4.创建一个对象，比如new Date()，除了Date对象内部存储的数据(例如年月日等信息)占用的内存，该对象本身也有内存开销，每个对象的自身开销是16个字节，用来保存对象的头信息。 5.一般内存的使用，如果不够8个字节，都会被自动填充为8字节的倍数字节数：
比如不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面 加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，就别处理，保证别重复处理相同的消息即可。
如测试的时候，将 url 改为一个不存在的 url：“http://test.com” ，超时时间 3000ms 过后，系统报出异常： org.apache.commons.httpclient.ConnectTimeoutException:The host did not accept the connection within timeout of 3000 ms
业务一开启全局事务，其中包含分支事务 A（修改 A）和分支事务 B（修改 B），业务二修改 A，其中业务一执行分支事务 A 先获取本地锁，业务二则等待业务一执行完分支事务 A 之后，获得本地锁修改 A 并入库，业务一在执行分支事务时发生异常了，由于分支事务 A 的数据被业务二修改，导致业务一的全局事务无法回滚。
如何防止脏写？
4.4.1.1. @GlobalTransactional
1、业务二执行时加 @GlobalTransactional 注解：
注：分支事务执行过程省略其它过程。
业务二在执行全局事务过程中，分支事务 A 提交前注册分支事务获取全局锁时，发现业务业务一全局锁还没执行完，因此业务二提交不了，抛异常回滚，所以不会发生脏写。
@Bean @ConditionalOnBean(MultipartResolver.class)//容器中有这个类型组件 @ConditionalOnMissingBean(name = DispatcherServlet.MULTIPART_RESOLVER_BEAN_NAME)//容器中没有这个名字 multipartResolver 的组件 public MultipartResolver multipartResolver(MultipartResolver resolver) { //给@Bean标注的方法传入了对象参数，这个参数的值就会从容器中找。 //SpringMVC multipartResolver。防止有些用户配置的文件上传解析器不符合规范 // Detect if the user has created a MultipartResolver but named it incorrectly return resolver; } 给容器中加入了文件上传解析器；
Spring 5.2.0+ 的版本，建议你的配置类均采用 Lite 模式去做，即显示设置 proxyBeanMethods = false。Spring Boot 在 2.2.0 版本（依赖于 Spring 5.2.0）起就把它的所有的自动配置类的此属性改为了 false，即@Configuration(proxyBeanMethods = false)，目的是为了提高 Spring 启动速度
spring core：提供了框架的基本组成部分，包括控制反转（Inversion of Control，IOC）和依赖注入（Dependency Injection，DI）功能。
spring beans：提供了 BeanFactory，是工厂模式的一个经典实现，Spring 将管理对象称为 Bean。
spring context：构建于 core 封装包基础上的 context 封装包，提供了一种框架式的对象访问方法。
spring jdbc：提供了一个 JDBC 的抽象层，消除了烦琐的 JDBC 编码和数据库厂商特有的错误代码解析， 用于简化 JDBC。
spring aop：提供了面向切面的编程实现，让你可以自定义拦截器、切点等。
spring Web：提供了针对 Web 开发的集成特性，例如文件上传，利用 servlet listeners 进行 ioc 容器初始化和针对 Web 的 ApplicationContext。
spring test：主要为测试提供支持的，支持使用 JUnit 或 TestNG 对 Spring 组件进行单元测试和集成测试。
2. IOC 相关
2.1. 什么是 IOC 容器
控制反转即 IOC (Inversion of Control)，它把传统上由程序代码直接操控的对象的调用权交给容器，通过容器来实现对象组件的装配和管理。所谓的“控制反转”概念就是对组件对象控制权的转移，从程序代码本身转移到了外部容器。 Spring IOC 负责创建对象，管理对象（通过依赖注入（DI）），装配对象，配置对象，并且管理这些对象的整个生命周期。
2.2. IOC 的作用和意义
作用
管理对象的创建和依赖关系的维护
解耦，由容器去维护具体的对象
托管了类的生成过程，比如我们无需去关心类是如何完成代理的
控制反转 控制了什么？ UserService service=new UserService(); // 耦合度太高 、维护不方便 引入 Ioc 就将创建对象的控制权交给 Spring 的 Ioc. 以前由程序员自己控制对象创建， 现在交给 Spring 的 Ioc 去创建， 如果要去使用对象需要通过 DI（依赖注入）@Autowired 自动注入 就可以使用对象 ;
意义 1. IOC 容器以最小的代价和最小的侵入性使松散耦合得以实现。 2. IOC 容器支持加载服务时的饿汉式初始化和懒加载。 ❕%% ▶10.🏡⭐️◼️IOC 容器的意义◼️⭐️-point-20230226-2231%%
2.3. IOC 的实现机制
工厂模式 + 反射
2.4. 什么是 Spring 的依赖注入 (DI)？IOC 和 DI 的区别是什么
很多人把 IOC 和 DI 说成一个东西，笼统来说的话是没有问题的，但是本质上还是有所区别的，希望大家能够严谨一点，IOC 和 DI 是从不同的角度描述的同一件事，IOC 是从容器的角度描述，而 DI 是从应用程序的角度来描述，也可以这样说，IOC 是依赖倒置原则的设计思想，而 DI 是具体的实现方式
@Autowired 默认按类型装配（属于 Spring 规范），默认情况下必须要求依赖对象必须存在，如果要允许 null 值，可以设置它的 required 属性为 false，如：@Autowired(required=false)。如果我们想使用名称装配可以结合@Qualifier 注解进行使用
@Resource（属于 J2EE 复返），默认按照名称进行装配，名称可以通过 name 属性进行指定。如果没有指定 name 属性，当注解写在字段上时，默认取字段名进行按照名称查找，如果注解写在 setter 方法上默认取属性名进行装配。当找不到与名称匹配的 bean 时才按照类型进行装配。但是需要注意的是，如果 name 属性一旦指定，就只会按照名称进行装配。
如测试的时候，将 url 改为一个不存在的 url：“http://test.com” ，超时时间 3000ms 过后，系统报出异常： org.apache.commons.httpclient.ConnectTimeoutException:The host did not accept the connection within timeout of 3000 ms
在大概了解了 MySQL 各种类型的索引，以及索引本身的利弊与判断一个字段是否须要创建索引之后，就要着手创建索引来优化 Query 了。在很多时候，WHERE 子句中的过滤条件并不只是针对于单一的某个字段，经常会有多个字段一起作为查询过滤条件存在于 WHERE 子句中。在这种时候，就必须要判断是该仅仅为过滤性最好的字段建立索引，还是该在所有字段（过滤条件中的）上建立一个组合索引。
1、先执行 From ->Where ->Group By->Order By 2、执行 From 字句是从右往左进行执行。因此必须选择记录条数最少的表放在右边。 3、对于 Where 字句其执行顺序是从后向前执行、因此可以过滤最大数量记录的条件必须写在 Where 子句的末尾，而对于多表之间的连接，则写在之前。 因为这样进行连接时，可以去掉大多不重复的项。 \4. SELECT 子句中避免使用 (_)ORACLE 在解析的过程中, 会将’_’ 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 6、用 UNION 替换 OR(适用于索引列) union: 是将两个查询的结果集进行追加在一起，它不会引起列的变化。 由于是追加操作，需要两个结果集的列数应该是相关的， 并且相应列的数据类型也应该相当的。union 返回两个结果集，同时将两个结果集重复的项进行消除。 如果不进行消除，用 UNOIN ALL.
通常情况下, 用 UNION 替换 WHERE 子句中的 OR 将会起到较好的效果. 对索引列使用 OR 将造成全表扫描. 注意, 以上规则只针对多个索引列有效. 如果有 column 没有被索引, 查询效率可能会因为你没有选择 OR 而降低. 在下面的例子中, LOC_ID 和 REGION 上都建有索引.
高效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 UNION SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE REGION = “MELBOURNE”
低效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 OR REGION = “MELBOURNE” 如果你坚持要用 OR, 那就需要返回记录最少的索引列写在最前面.
\7. 用 EXISTS 替代 IN、用 NOT EXISTS 替代 NOT IN 在许多基于基础表的查询中, 为了满足一个条件, 往往需要对另一个表进行联接. 在这种情况下, 使用 EXISTS(或 NOT EXISTS) 通常将提高查询的效率. 在子查询中, NOT IN 子句将执行一个内部的排序和合并. 无论在哪种情况下, NOT IN 都是最低效的 (因为它对子查询中的表执行了一个全表遍历). 为了避免使用 NOT IN, 我们可以把它改写成外连接 (Outer Joins) 或 NOT EXISTS.
例子：
高效: SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND EXISTS (SELECT ‘X’ FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB’)
低效: SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND DEPTNO IN(SELECT DEPTNO FROM DEPT WHERE LOC = ‘MELB’)
SELECT Col FROM tbl WHERE substr(name ,1 ,3 ) = ‘ABC’ 或者 SELECT Col FROM tbl WHERE name LIKE ‘%ABC%’ 而 SELECT Col FROM tbl WHERE name LIKE ‘ABC%’ 会使用索引。
SELECT Col FROM tbl WHERE col / 10 > 10 则会使索引失效，应该改成 SELECT Col FROM tbl WHERE col > 10 * 10
5.2. 字符串不加单引号 - 存在隐式类型转换
在查询时，没有对字符串加单引号，MySQL 的查询优化器，会自动的进行类型转换，造成索引失效。
5.3. 用 or 连接没有索引的列 - 都失效
如果 or 前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。 示例，name 字段是索引列，而 createtime 不是索引列，中间是 or 进行连接是不走索引的 ：
using index ：使用覆盖索引的时候就会出现using where：在查找使用索引的情况下，需要回表去查询所需的数据using index condition：查找使用了索引下推，但仍需要少量回表查询数据using index ; using where：查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据
如果某列建立索引，当进行 Select * from emp where depto is not null/is null。则可能会使索引失效。是因为 MySQL 进行了成本计算，如果 null 值太多，那么 is null 成本太高，还不如全表扫描，所以不会走索引，而 is not null 就会走索引。反之亦然。
https://xiaolincoding.com/mysql/base/how_select.html#%E6%89%A7%E8%A1%8C%E5%99%A8 简称 ICP，Index Condition Pushdown(ICP) 是 MySQL5.6 中新特性，是⼀种在存储引擎层使⽤索引过滤数据的⼀种优化⽅式，ICP 可以减少存储引擎访问基表的次数以及 MySQL 服务器访问存储引擎的次数。举个例⼦来说⼀下：我们需要查询 name 以 javacode35 开头的，性别为 1 的记录数，sql 如下： select count(id) from test1 a where name like ‘javacode35%’ and sex = 1;
6.3.1. 一般过程
⾛ name 索引检索出以 javacode35 的第⼀条记录，得到记录的 id
利⽤ id 去主键索引中查询出这条记录 R1
判断 R1 中的 sex 是否为 1，然后重复上⾯的操作，直到找到所有记录为⽌。 上⾯的过程中需要⾛ name 索引以及需要回表操作。
MySQL 的性能优化我认为可以分为 4 大部分 l 硬件和操作系统层面的优化 l 架构设计层面的优化 l MySQL 程序配置优化 l SQL 优化硬件及操作系统层面优化从硬件层面来说，影响 Mysql 性能的因素有，CPU、可用内存大小、磁盘读写速度、网络带宽从操作系层面来说，应用文件句柄数、操作系统网络的配置都会影响到 Mysql 性能。这部分的优化一般由 DBA 或者运维工程师去完成。在硬件基础资源的优化中，我们重点应该关注服务本身承载的体量，然后提出合理的指标要求，避免出现资源浪费！ 架构设计层面的优化 MySQL 是一个磁盘 IO 访问量非常频繁的关系型数据库 在高并发和高性能的场景中.MySQL 数据库必然会承受巨大的并发压力，而此时，我们的优化方式可以分为几个部分。 1. 搭建 Mysql 主从集群，单个 Mysql 服务容易单点故障，一旦服务器宕机，将会导致依赖 Mysql 数据库的应用全部无法响应。主从集群或者主主集群可以保证服务的高可用性。 2. 读写分离设计，在读多写少的场景中，通过读写分离的方案，可以避免读写冲突导致的性能影响 3. 引入分库分表机制，通过分库可以降低单个服务器节点的 IO 压力，通过分表的方式可以降低单表数据量，从而提升 sql 查询的效率。 4. 针对热点数据，可以引入更为高效的分布式数据库，比如 Redis、MongoDB 等，他们可以很好的缓解 Mysql 的访问压力，同时还能提升数据检索性能。 MySQL 程序配置优化 MySQL 是一个经过互联网大厂验证过的生产级别的成熟数据库，对于 Mysql 数据库本身的优化，一般是通过 Mysql 中的配置文件 my.cnf 来完成的，比如。 Mysql5.7 版本默认的最大连接数是 151 个，这个值可以在 my.cnf 中修改。 binlog 日志，默认是不开启缓存池 bufferpoll 的默认大小配置等。由于这些配置一般都和用户安装的硬件环境以及使用场景有关系，因此这些配置官方只会提供一个默认值，具体情况还得由使用者来修改。关于配置项的修改，需要关注两个方面 l 配置的作用域，分为会话级别和全局 l 是否支持热加载因此，针对这两个点，我们需要注意的是： l 全局参数的设定对于已经存在的会话无法生效 l 会话参数的设定随着会话的销毁而失效 l 全局类的统一配置建议配置在默认配置文件中，否则重启服务会导致配置失效 SQL 优化又能分为三步曲 l 第一、慢 SQL 的定位和排查我们可以通过慢查询日志和慢查询日志分析工具得到有问题的 SQL 列表。 l 第二、执行计划分析 针对慢 SQL，我们可以使用关键字 explain 来查看当前 sql 的执行计划.可以重点 关注 type key rows filterd 等字段 ，从而定位该 SQL 执行慢的根本原因。再有 的放矢的进行优化 l 第三、使用 show profile 工具 Show Profile 是 MySQL 提供的可以用来分析当前会话中，SQL 语句资源消耗情 况的工具，可用于 SQL 调优的测量。在当前会话中.默认情况下处于 show profile 是关闭状态，打开之后保存最近 15 次的运行结果 针对运行慢的 SQL，通过 profile 工具进行详细分析.可以得到 SQL 执行过程中 所有的资源开销情况. 如 IO 开销,CPU 开销,内存开销等. 以上就是我对 MySQL 性能优化的理解。 好的，看完高手的回答后，相信各位对 MySQL 性能优化有了一定的理解了，最 后我在给各位总结一下常见的 SQL 优化规则： l SQL 的查询一定要基于索引来进行数据扫描 l 避免索引列上使用函数或者运算,这样会导致索引失效 l where 字句中 like %号,尽量放置在右边 l 使用索引扫描,联合索引中的列从左往右,命中越多越好. l 尽可能使用 SQL 语句用到的索引完成排序,避免使用文件排序的方式 l 查询有效的列信息即可.少用 * 代替列信息 l 永远用小结果集驱动大结果集
Mysql 从 5.0.37 版本开始增加了对 show profiles 和 show profile 语句的支持。show profiles 能够在做 SQL 优化时帮助我们了解时间都耗费到哪里去了。
通过 have_profiling 参数，能够看到当前 MySQL 是否支持 profile：
1 2 3 4
select version(); -- 先查看mysql版本是否高于5.0.37 show variables like 'have_profiling'; -- 首先查看是否支持该功能 set profiling=on; -- 默认是关闭的，开启该功能 show variables like 'profiling%'; -- 查看开启状态。15表示历史缓存sql的个数
执行完上述命令之后，再执行 show profiles 指令，来查看 SQL 语句执行的耗时：
5.1. show profiles
5.2. show profile for query x
TIP ： Sending data 状态表示 MySQL 线程开始访问数据行并把结果返回给客户端，而不仅仅是返回个客户端。由于在 Sending data 状态下，MySQL 线程往往需要做大量的磁盘读取操作，所以经常是整个查询中耗时最长的状态。
在获取到最消耗时间的线程状态后，MySQL 支持进一步选择 all、cpu、block io 、context switch、page faults 等明细类型类查看 MySQL 在使用什么资源上耗费了过高的时间。例如，选择查看 CPU 的耗费时间 ：
6. trace- 分析优化器执行计划
MySQL5.6 提供了对 SQL 的跟踪 trace, 通过 trace 文件能够进一步了解为什么优化器选择 A 计划, 而不是选择 B 计划。
1bit 符号位标识，由于 long 基本类型在 Java 中是带符号的，最高位是符号位，正数是 0，负数是 1，所以 id 一般是正数，最高位是 0。 **41bit 时间截 (毫秒级)**，存储的是时间截的差值（当前时间截 - 开始时间截)，结果约等于 69.73 年。 10bit 作为机器的 ID（5 个 bit 是数据中心，5 个 bit 的机器 ID，可以部署在 1024 个节点）。 12bit 作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID）。
7.2. 优点
整体上按照时间自增排序，并且整个分布式系统内不会产生 ID 碰撞，并且效率较高。Twitter 测试的峰值是 10 万个每秒。另外，美团公司开源了一个全局唯一 id 生成系统 leaf，它里面也用到了雪花算法去构建全局唯一 id 并且在高性能和高可用方面，做了很多的优化，为美团内部业务提供了每天上亿次的调用。
Redis 不可能时时刻刻遍历所有被设置了生存时间的 key，来检测数据是否已经到达过期时间，然后对它进行删除。立即删除能保证内存中数据的最大新鲜度，因为它保证过期键值会在过期后马上被删除，其所占用的内存也会随之释放。但是立即删除对 cpu 是最不友好的。因为删除操作会占用 cpu 的时间，如果刚好碰上了 cpu 很忙的时候，比如正在做交集或排序等计算的时候，就会给 cpu 造成额外的压力，让 CPU 心累，时时需要删除，忙死。。。。。。这会产生大量的性能消耗，同时也会影响数据的读取操作。
面对互联网复杂的业务系统，基本可以将服务网关分成两类：流量网关和业务网关。 流量网关：跟具体的后端业务系统和服务完全无关的部分，比如安全策略、全局性流控策略、流量分发策略等。 业务网关：针对具体的后端业务系统，或者是服务和业务有一定关联性的部分，并且一般被直接部署在业务服务的前面。业务网关一般部署在流量网关之后，业务系统之前，比流量网关更靠近系统。我们大部分情况下说的 API 网关，狭义上指的是业务网关。并且如果系统的规模不大，我们也会将两者合二为一，使用一个网关来处理所有的工作
Docker 是一种轻量级的虚拟化技术，同时是一个开源的应用容器运行环境搭建平台，可以让开发者以便捷方式打包应用到一个可移植的容器中，然后安装至任何运行 Linux 或 Windows 等系统的服务器上。相较于传统虚拟机，Docker 容器提供轻量化的虚拟化方式、安装便捷、启停速度快。 Docker 是基于 Go 语言实现的云开源项目。 Docker 的主要目标是“Build，Ship and Run Any App,Anywhere”，也就是通过对应用组件的封装、分发、部署、运行等生命周期的管理，使用户的 APP（可以是一个 WEB 应用或数据库应用等等）及其运行环境能够做到“一次镜像，处处运行”。
The main purpose of a CMD is to provide defaults for an executing container. These defaults can include an executable, or they can omit the executable, in which case you must specify an ENTRYPOINT instruction as well.
当 GC 进入到标记阶段且 oldobj 没被标记时，则标记 oldobj，并将其记录。也就是说，在标记阶段中如果指针更新前引用的 oldobj 是白色对象，就将其涂成灰色。 上图依旧是对象消失的例子。a 到 b 中，产生了一条由 A 到 C 的引用关系，这里并没有像增量更新那样将 A 或者 C 标为灰色，相反原始快照中允许出现从黑色指向白色的引用。而在从 b 到 c 中，删除了由 B 到 C 的引用关系。这时候就需要进行处理，将 C 涂为灰色。
Serial 收集器采用复制算法、串行回收和 “stop-the-World” 机制的方式执行内存回收。 除了年轻代之外，Serial 收集器还提供用于执行老年代垃圾收集的 Serial Old 收集器。Serial Old 收集器同样也采用了串行回收和 “Stop the World” 机制，只不过内存回收算法使用的是标记 - 压缩算法。
Serial old 是运行在 Client 模式下默认的老年代的垃圾回收器
Serial 0ld 在 Server 模式下主要有两个用途： ① 与新生代的 Parallel scavenge 配合使用 ② 作为老年代 CMS 收集器的后备垃圾收集方案
当越来越多的对象晋升到老年代 old region 时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即 Mixed GC，该算法并不是一个 Old GC，除了回收整个 Young Region，还会回收一部分的 Old Region。这里需要注意：是一部分老年代，而不是全部老年代。可以选择哪些 Old Region 进行收集，从而可以对垃圾回收的耗时时间进行控制。也要注意的是 Mixed GC 并不是 Full GC。
drop table if exists test_innodb_lock; CREATE TABLE test_innodb_lock ( a INT (11), b VARCHAR (20) ) ENGINE INNODB DEFAULT charset = utf8; insert into test_innodb_lock values (1,'a'); insert into test_innodb_lock values (2,'b'); insert into test_innodb_lock values (3,'c'); insert into test_innodb_lock values (4,'d'); insert into test_innodb_lock values (5,'e');
1 2
create index idx_lock_a on test_innodb_lock(a); create index idx_lock_b on test_innodb_lock(b);
CREATE TABLE users( id INT NOT NULL, name VARCHAR(20) NOT NULL, age INT NOT NULL, PRIMARY KEY(id) );
1 2 3 4 5
insert into users values (1,'a',11); insert into users values (2,'a',12); insert into users values (3,'a',13); insert into users values (4,'a',14); insert into users values (5,'a',15);
1
select ENGINE_TRANSACTION_ID,LOCK_TYPE,LOCK_MODE from performance_schema.data_locks where ENGINE_TRANSACTION_ID in (1862);
]]> MySQL 锁 框架源码专题-MySQL-3、redolog undolog binlog/2023/02/14/002-%E6%A1%86%E6%9E%B6%E6%BA%90%E7%A0%81%E4%B8%93%E9%A2%98/MySQL-3%E3%80%81redolog-undolog-binlog/
1. 日志流程图
逻辑日志： 可以简单理解为记录的就是 sql 语句。
物理日志：mysql 数据最终是保存在数据页中的，物理日志记录的就是数据页变更。
只有 Redolog 是物理日志，Binlog 和 Undolog 都是逻辑日志。
2. Binlog
逻辑日志
2.1. 记录内容 - DDL 和 DML
binlog 用于记录数据库执行的写入性操作 (DDL 和 DML)信息，以二进制的形式保存在磁盘中。binlog 是 mysql 的逻辑日志，并且由 Server 层进行记录，使用任何存储引擎的 mysql 数据库都会记录 binlog 日志 比如 update T set c=c+1 where ID=2; 这条 SQL，redo log 中记录的是 ：xx页号，xx偏移量的数据修改为xxx；binlog 中记录的是：id = 2 这一行的 c 字段 +1
binlog 文件是记录了所有数据库表结构变更和表数据修改的日志，不会记录查询类的操作，比如 SELECT 和 SHOW 操作。
]]> MySQL MySQL 日志文件 框架源码专题-MySQL-2、MVCC/2023/02/13/002-%E6%A1%86%E6%9E%B6%E6%BA%90%E7%A0%81%E4%B8%93%E9%A2%98/MySQL-2%E3%80%81%E4%BA%8B%E5%8A%A1-MVCC-LBCC/
]]> MySQL MySQL MVCC Java基础-关键字和接口-7、Throwable/2023/02/12/001-%E5%9F%BA%E7%A1%80%E7%9F%A5%E8%AF%86%E4%B8%93%E9%A2%98/%E5%85%B3%E9%94%AE%E5%AD%97%E5%92%8C%E6%8E%A5%E5%8F%A3-7%E3%80%81Throwable/
]]> Spring 框架源码专题 Spring 面试专题-2、Spring事务/2023/02/11/011-%E9%9D%A2%E8%AF%95%E9%A2%98%E4%B8%93%E9%A2%98/%E9%9D%A2%E8%AF%95%E4%B8%93%E9%A2%98-2%E3%80%81Spring-%E4%BA%8B%E5%8A%A1/
]]> Spring 框架源码专题 Spring IOC 框架源码专题-Spring-7、扩展点/2023/01/28/002-%E6%A1%86%E6%9E%B6%E6%BA%90%E7%A0%81%E4%B8%93%E9%A2%98/Spring-7%E3%80%81%E6%89%A9%E5%B1%95%E7%82%B9/
]]> 框架源码专题 timeline 框架源码专题 Spring IOC 内功心法专题-设计模式-0、设计模式总结/2023/01/24/009-%E5%86%85%E5%8A%9F%E5%BF%83%E6%B3%95%E4%B8%93%E9%A2%98/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-0%E3%80%81%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E6%80%BB%E7%BB%93/
SynchronizedQueue，又称无缓冲队列。比较特别的是 SynchronizedQueue 内部不会存储元素。与 ArrayBlockingQueue、LinkedBlockingQueue 不同，SynchronizedQueue 直接使用 CAS 操作控制线程的安全访问。其中 put 和 take 操作都是阻塞的，每一个 put 操作都必须阻塞等待一个 take 操作，反之亦然。所以 SynchronizedQueue 可以理解为生产者和消费者配对的场景，双方必须互相等待，直至配对成功。在 JDK 的线程池 Executors.newCachedThreadPool 中就存在 SynchronousQueue 的运用，对于新提交的任务，如果有空闲线程，将重复利用空闲线程处理任务，否则将新建线程进行处理。
LinkedTransferQueue，一种特殊的无界阻塞队列，可以看作 LinkedBlockingQueues、SynchronousQueue（公平模式）、ConcurrentLinkedQueue 的合体。与 SynchronousQueue 不同的是，LinkedTransferQueue 内部可以存储实际的数据，当执行 put 操作时，如果有等待线程，那么直接将数据交给对方，否则放入队列中。与 LinkedBlockingQueues 相比，LinkedTransferQueue 使用 CAS 无锁操作进一步提升了性能。
//获取下一个元素 public E next() { checkForComodification(); inti= cursor; if (i >= size) thrownewNoSuchElementException(); Object[] elementData = ArrayList.this.elementData; if (i >= elementData.length) thrownewConcurrentModificationException(); cursor = i + 1; return (E) elementData[lastRet = i]; } ... }
安全组合模式 在安全组合模式中，在抽象构件角色中没有声明任何用于管理成员对象的方法，而是在树枝节点 Menu 类中声明并实现这些方法。安全组合模式的缺点是不够透明，因为叶子构件和容器构件具有不同的方法，且容器构件中那些用于管理成员对象的方法没有在抽象构件类中定义，因此客户端不能完全针对抽象编程，必须有区别地对待叶子构件和容器构件。
classTimSort<T> { static <T> voidsort(T[] a, int lo, int hi, Comparator<? super T> c, T[] work, int workBase, int workLen) { assert c != null && a != null && lo >= 0 && lo <= hi && hi <= a.length;
intnRemaining= hi - lo; if (nRemaining < 2) return; // Arrays of size 0 and 1 are always sorted
// If array is small, do a "mini-TimSort" with no merges if (nRemaining < MIN_MERGE) { intinitRunLen= countRunAndMakeAscending(a, lo, hi, c); binarySort(a, lo, hi, lo + initRunLen, c); return; } ... }
privatestatic <T> intcountRunAndMakeAscending(T[] a, int lo, int hi,Comparator<? super T> c) { assert lo < hi; intrunHi= lo + 1; if (runHi == hi) return1;
// Find end of run, and reverse range if descending if (c.compare(a[runHi++], a[lo]) < 0) { // Descending while (runHi < hi && c.compare(a[runHi], a[runHi - 1]) < 0) runHi++; reverseRange(a, lo, runHi); } else { // Ascending while (runHi < hi && c.compare(a[runHi], a[runHi - 1]) >= 0) runHi++; }
从执行步骤中可以看到：HandlerAdapter 对于执行流程的通用性起到了非常重要的作用，它能把任何一个处理器（Object）都适配成一个 HandlerAdapter，从而可以做统一的流程处理，这也是为何DispatcherServlet它能作为其它 web 处理框架的分发器的原因（因为它没有耦合具体的处理器，我们完全可以自己去实现）
6.2.2. 扩展性分析⭐️🔴⭐️🔴
6.2.2.1. 适配器 HandlerAdapter⭐️🔴
为什么要用适配器 HandlerAdapter
Spring MVC 的 Handler 有四种不同的表现形式，包括 Controller 接口，HttpRequestHandler，Servlet、@RequestMapping，那么调用方式就不是确定的，如果需要直接调用 Controller 方法，需要调用的时候就得不断使用 if else 来进行判断是哪一种子类然后执行。 如果后面要扩展 Controller，就得修改原来的代码，这样违背了开闭原则。❕%% 1710-🏡⭐️◼️SpringMVC 为什么要用适配器模式 ?🔜MSTM📝 ◼️⭐️-point-202302071710%%
1155-🏡⭐️◼️Proxy.newProxyInstance(loader, interfaces, new InvocationHandler() {xxx})中的第二个参数是目标类所实现的所有接口，意义是一个代理类可以代理目标类所有接口中的所有方法。代理类与目标类实现了相同的接口，起点是在这里配置的◼️⭐️-point-202301261155%%
Enum constants are serialized differently than ordinary serializable or externalizable objects. The serialized form of an enum constant consists solely of its name; field values of the constant are not present in the form. To serialize an enum constant, ObjectOutputStream writes the value returned by the enum constant’s name method. To deserialize an enum constant, ObjectInputStream reads the constant name from the stream; the deserialized constant is then obtained by calling the java.lang.Enum.valueOf method, passing the constant’s enum type along with the received constant name as arguments. Like other serializable or externalizable objects, enum constants can function as the targets of back references appearing subsequently in the serialization stream. The process by which enum constants are serialized cannot be customized: any class-specific writeObject, readObject, readObjectNoData, writeReplace, and readResolve methods defined by enum types are ignored during serialization and deserialization. Similarly, any serialPersistentFields or serialVersionUID field declarations are also ignored–all enum types have a fixedserialVersionUID of 0L. Documenting serializable fields and data for enum types is unnecessary, since there is no variation in the type of data sent.
/** * Returns the runtime object associated with the current Java application. * Most of the methods of class <code>Runtime</code> are instance * methods and must be invoked with respect to the current runtime object. * * @return the <code>Runtime</code> object associated with the current * Java application. */ publicstatic Runtime getRuntime() { return currentRuntime; }
/** Don't let anyone else instantiate this class */ privateRuntime() {} ... }
public CompletableFuture<T> whenComplete(BiConsumer<? super T,? super Throwable> action); public CompletableFuture<T> whenCompleteAsync(BiConsumer<? super T,? super Throwable> action); public CompletableFuture<T> whenCompleteAsync(BiConsumer<? super T,? super Throwable> action, Executor executor);
public CompletableFuture<T> exceptionally(Function<Throwable,? extends T> fn);
whenComplete可以处理正常和异常的计算结果，exceptionally处理异常情况。BiConsumer<? super T,? super Throwable>可以定义处理业务
public <U> CompletableFuture<U> thenApply(Function<? super T,? extends U> fn) public <U> CompletableFuture<U> thenApplyAsync(Function<? super T,? extends U> fn) public <U> CompletableFuture<U> thenApplyAsync(Function<? super T,? extends U> fn, Executor executor)
public CompletionStage<Void> thenAccept(Consumer<? super T> action); public CompletionStage<Void> thenAcceptAsync(Consumer<? super T> action); public CompletionStage<Void> thenAcceptAsync(Consumer<? super T> action,Executor executor);
public CompletionStage<Void> thenRun(Runnable action); public CompletionStage<Void> thenRunAsync(Runnable action); public CompletionStage<Void> thenRunAsync(Runnable action,Executor executor);
CPU 密集型也就是计算密集型，常常指算法复杂的程序，需要进行大量的逻辑处理与计算，CPU 在此期间是一直在工作的。 在这种情况下 CPU 的利用率会非常高，我们的最大核心数设置为 CPU 的核心数即可。 这种情况下 CPU 几乎满负荷运行，我们配置的数字在大也没有效果，反而会增大额外的切换开销。 在《Java Concurrency in Practice》中，推荐将 CPU 密集型最大线程数设置为 最大线程数 = CPU 核心数 + 1，这样能发挥最高效率。 核心线程数一般会设置为 **核心线程数 = 最大线程数 * 20%**。
4.2. IO 密集型
IO 密集型是指我们程序更多的工作是在通过磁盘、内存或者是网络读取数据，在 IO 期间我们线程是阻塞的，这期间 CPU 其实也是空闲的，这样我们的操作系统就可以切换其他线程来使用 CPU 资源。 通常在进行接口远程调用，数据库数据获取，缓冲数据获取都属于 IO 操作。 这时我们线程数可以通过以下公式进行计算：最大线程数 = CPU 核心数 / （1 - 阻塞占百分比）。
订阅的同一个 Topic 中的 Tag 必须一致，包括 Tag 的数量和 Tag 的顺序，例如：Consumer1 订阅 TopicB 且 Tag 为 Tag1||Tag2，Consumer2 订阅 TopicB 的 Tag 也必须是 Tag1||Tag2，不能只订阅 Tag1、只订阅 Tag2 或者订阅 Tag2||Tag1。
MySQL 的二级索引分为唯一和非唯一两种，而对一个拥有二级索引的列做 DML，同时需要维护更新这个列上的索引。维护更新索引的这个操作，也就是根据列上的值，按照索引排序规则，将该列对应的索引块进行相关维护。而在做维护的时候，自然是要把索引块从磁盘读到 buffer pool 里。那么最理想的情况就是需要维护的索引块已经在 buffer pool 里了，就不需要再去磁盘里找出相应的索引块，也就节省了一些随机 IO。
]]> MySQL MySQL MySQL日志 框架源码专题-RocketMQ-1、基本原理/2022/12/31/005-%E5%88%86%E5%B8%83%E5%BC%8F%E4%B8%93%E9%A2%98/%E5%88%86%E5%B8%83%E5%BC%8F%E4%B8%93%E9%A2%98-MQ-RocketMQ-1%E3%80%81%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86/1. 历史
CAP 是 Consistency、Availability、Partition tolerance 三个词语的缩写，分别表示一致性、可用性、分区容忍性。
3.1.1. CAP 组合方式
1）AP： 放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。 例如： 上边的商品管理，完全可以实现 AP，前提是只要用户可以接受所查询的到数据在一定时间内不是最新的即可。 通常实现 AP 都会保证最终一致性，后面讲的 BASE 理论就是根据 AP 来扩展的，一些业务场景 比如：订单退款，今 日退款成功，明日账户到账，只要用户可以接受在一定时间内到账即可。
通过上面我们已经学习了 CAP 理论的相关知识，CAP 是一个已经被证实的理论：一个分布式系统最多只能同时满足 一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它可以作 为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的 集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 N 个 9（99.99..%），并要达到良 好的响应性能来提高用户体验，因此一般都会做出如下选择：保证 P 和 A，舍弃 C 强一致，保证最终一致性。
3.2. BASE 理论
3.2.1. 强一致性和最终一致性
CAP 理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项，其中 AP 在实际应用中较多，AP 即舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，比如前边我们举的例子主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和 CAP 中的一致性不同，CAP 中的一致性要求 在任何时间查询每个结点数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内每个结点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。
3.2.2. Base 理论
BASE 是 Basically Available(基本可用)、Soft state(软状态) 和 Eventually consistent (最终一致性) 三个短语的缩写。BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足 BASE 理论的事务，我们称之为“柔性事务”。
XA 方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身（通过提供支持 XA 的驱动程序来供应用使用）。而 Seata 的 RM 是以二方包的形式作为中间件层部署在应用程序这一侧的，不依赖与数据库本身对协议的支持，当然也不需要数据库支持 XA 协议。这点对于微服务化的架构来说是非常重要的：应用层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。
E - Element (在集合中使用，因为集合中存放的是元素) T - Type（表示 Java 类，包括基本的类和我们自定义的类） K - Key（表示键，比如 Map 中的 key） V - Value（表示值） N - Number（表示数值类型） ？ - （表示不确定的 java 类型） S、U、V - 2nd、3rd、4th types
AQS 采用了一个 volatile int 类型的互斥变量 state 用来记录锁竞争的一个状态，0 表示当前没有任何线程竞争锁资源，而大于等于 1 表示已经有线程正在持有锁资源。 一个线程来获取锁资源的时候，首先判断 state 是否等于 0，如果是 (无锁状态)，则把这个 state 通过 CAS 更新成 1，表示占用到锁。此时如果多个线程进行同样的操作，会造成线程安全问题。AQS 采用了 CAS 机制来保证互斥变量 state 的原子性。 未获取到锁资源的线程通过 LockSupport 的 park 方法 (底层是 Unsafe 类的 park 方法) 对线程进行阻塞，把阻塞的线程按照先进先出的原则加入到一个双向链表的结构中，当获得锁资源的线程释放锁之后，会从双向链表的头部去唤醒下一个等待的线程再去竞争锁。 另外关于公平性和非公平性问题，AQS 的处理方式是，在竞争锁资源的时候，公平锁需要判断双向链表中是否有阻塞的线程，如果有，则需要去排队等待；而非公平锁的处理方式是，不管双向链表中是否存在等待锁的线程，都会直接尝试更改互斥变量 state 去竞争锁。
Spring-1、基本原理]]> Spring 框架源码专题 Spring Java基础-基本原理-1、反射/2022/12/09/001-%E5%9F%BA%E7%A1%80%E7%9F%A5%E8%AF%86%E4%B8%93%E9%A2%98/%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86-1%E3%80%81%E5%8F%8D%E5%B0%84/1. 定义
多态也在普通方式的范畴内。RTTI，即 Run-Time Type Identification 运行时类型认定，通过运行时类型信息程序能够使用父类的指针或引用来检查这些指针或引用所指的对象的实际派生类型，是多态实现的技术基础。RTTI 的功能主要是通过 Class 类文件实现的，更精确一点是通过 Class 类文件的方法表实现的。虽然是运行时判断所调用方法具体属于哪个类型，但是父类、子类的所有信息，在编译期是已经知道的了，即.class 文件在编译时已经获取到了。而对于反射机制来说，.class 文件在编译时是不可获取的，在运行时才获取到。
IOC 的全称是 Inversion Of Control, 也就是控制反转，它的核心思想是把对象的管理权限交给容器。应用程序如果需要使用到某个对象实例，直接从 IOC 容器中去获取就行，这样设计的好处是降低了程序里面对象与对象之间的耦合性。使得程序的整个体系结构变得更加灵活。
2.1.1. Bean 定义注册
Spring 里面很多方式去定义 Bean，（如图）比如 XML 里面的 <bean> 标签、@Service、 @Component、@Repository、@Configuration 配置类中的@Bean 注解等等。 Spring 在启动的时候，会去解析这些 Bean 然后保存到 IOC 容器里面。
2.1.2. IOC 容器的初始化
这个阶段主要是根据程序中定义的 XML 或者注解等 Bean 的声明方式 (如图）通过解析和加载后生成 BeanDefinition，然后把 BeanDefinition 注册到 IOC 容器 通过注解或者 xml 声明的 bean 都会解析得到一个 BeanDefinition 实体，实体中包含 这个 bean 中定义的基本属性。 最后把这个 BeanDefinition 保存到一个 Map 集合里面，从而完成了 IOC 的初始化。 IoC 容器的作用就是对这些注册的 Bean 的定义信息进行处理和维护，它 IoC 容器控制 反转的核心。
A->B: context.getBean(A) 开始创建 A，A 实例化完成后给 A 的依赖属性 b 开始赋值
B->A: context.getBean(B) 开始创建 B，B 实例化完成后给 B 的依赖属性 a 开始赋值
重点：此时因为 A 支持循环依赖，而且没有动态代理所以会执行 A 的 getEarlyBeanReference 方法得到它的早期引用。而执行 getEarlyBeanReference() 的时候因为@Async 根本还没执行，所以最终返回的仍旧是原始对象的地址
B 完成初始化、完成属性的赋值，此时属性 field 持有的是 Bean A原始类型的引用
继续 A 的创建流程：完成了 A 的属性的赋值（此时已持有 B 的实例的引用），继续执行初始化方法 initializeBean(…)，在此处会解析@Aysnc 注解，从而生成一个代理对象，所以最终 exposedObject 是一个代理对象（而非原始对象）最终加入到容器里
%% ▶11.🏡⭐️◼️【原因是 ABA 时，A 实例化完成将原始类型引用放入三级缓存，属性填充 B 时触发 B 的创建流程，B 实例化完成后填充属性时从三级缓存中拿到的是原始类型的 A 的早期引用，B 创建完成后，继续 A 的创建流程，但最后初始化完成后 A 上的@Async 注解生效生成了动态代理，但是 B 中的引用还是原始类型的引用，造成前后不一致】◼️⭐️-point-20230303-2035%% ^vlhwms
上演尴尬的场面：B 引用的属性 A 是个原始对象，而此处准备 return 的实例 A 竟然是个代理对象，也就是说 B 引用的并非是最终对象（不是最终放进容器里的对象） 执行自检程序：由于 allowRawInjectionDespiteWrapping 默认值是 false，表示不允许上面不一致的情况发生，so 最终就抛错了
]]> 框架源码专题 框架源码专题 Spring IOC 框架源码专题-Spring-3、AOP/2022/12/04/002-%E6%A1%86%E6%9E%B6%E6%BA%90%E7%A0%81%E4%B8%93%E9%A2%98/Spring-3%E3%80%81AOP%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86-@EnableAspectJAutoProxy/1. AOP
privatefinal MethodBeforeAdvice advice; /** * 为指定的advice创建对应的MethodBeforeAdviceInterceptor对象 * * Create a new MethodBeforeAdviceInterceptor for the given advice. * @param advice the MethodBeforeAdvice to wrap */publicMethodBeforeAdviceInterceptor(MethodBeforeAdvice advice) { Assert.notNull(advice, "Advice must not be null"); this.advice = advice; }
spring-context-support 模块是对 Spring IoC 容器及 IoC 子容器的扩展支持。
spring-context-indexer 模块是 Spring 的类管理组件和 Classpath 扫描组件。
spring-expression 模块是统一表达式语言（EL）的扩展模块，可以查询、管理运行中的对象，同时也可以方便地调用对象方法，以及操作数组、集合等。它的语法类似于传统 EL，但提供了额外的功能，最出色的要数函数调用和简单字符串的模板函数。EL 的特性是基于 Spring 产品的需求而设计的，可以非常方便地同 Spring IoC 进行交互。
19.1.1. 7.1.1 bean 概述
Spring 就是面向 Bean 的编程（BOP,Bean Oriented Programming），Bean 在 Spring 中处于核心地位。Bean 对于 Spring 的意义就像 Object 对于 OOP 的意义一样，Spring 中没有 Bean 也就没有 Spring 存在的意义。Spring IoC 容器通过配置文件或者注解的方式来管理 bean 对象之间的依赖关系。
如果 A happens-before B，且 B happens-before C，那么 A happens-before C。
1.4.6. start() 规则-子线程可见
如果线程 A 执行操作 ThreadB.start()（启动线程 B），那么 A 线程的 ThreadB.start() 操作 happens-before 于线程 B 中的任意操作。 主要含义是：线程 A 在启动子线程 B 之前对共享变量的修改结果对线程 B 可见。
1.4.7. join() 规则
如果线程 A 执行操作 ThreadB.join() 并成功返回，那么线程 B 中的任意操作 happens-before 于线程 A 从 ThreadB.join() 操作成功返回。 主要含义是：如果在线程 A 执行过程中调用了线程 B 的 join 方法，那么当 B 执行完成后，在线程 B 中所有操作结果对线程 A 可见。
在多 cpu 下，当其中一个处理器要对共享内存进行操作的时候，在总线上发出一个 LOCK# 信号，这个信号使得其他处理器无法通过总线来访问到共享内存中的数据，总线锁定把 CPU 和内存之间的通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，总线锁定的开销比较大，这种机制显然是不合适的。
1
总线锁的力度太大了，最好的方法就是控制锁的保护粒度，只需要保证对于被多个 CPU 缓存的同一份数据是一致的就可以了。所以引入了缓存锁。
此方法的调用是建议 JVM 进行 Full GC, 虽然只是建议而非一定, 但很多情况下它会触发 Full GC, 从而增加 Full GC 的频率, 也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过 -XX:+ DisableExplicitGC 来禁止 RMI 调用 System.gc。
1.4.2. 老年代代空间不足
老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行 Full GC 后空间仍然不足，则抛出如下错误： java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的 Full GC，调优时应尽量做到让对象在 Minor GC 阶段被回收、让对象在新生代多存活一段时间；不要创建过大的对象及数组。 ^0m8k82
1.4.3. 方法区空间不足
JVM 规范中运行时数据区域中的方法区，在 HotSpot 虚拟机中又被习惯称为永生代或者永生区，Permanet Generation 中存放的为一些 class 的信息、常量、静态变量等数据，当系统中要 加载的类、反射的类和调用的方法较多 时，Permanet Generation 可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么 JVM 会抛出如下错误信息： java.lang.OutOfMemoryError: PermGen space 为避免 Perm Gen 占满造成 Full GC 现象，可采用的方法为增大 Perm Gen 空间或转为使用 CMS GC。
1、诸葛结合了 volatile，把原因归结为写无效，比如 2 个线程都 use 后计算了新值，线程 2 出了问题没来得及 assign，没有触发 MESI 协议，但是第一个线程正常触发 MESI 协议，线程 2 也通过总线嗅探机制，收到了已经变化的信号，那么第 2 个线程没来得及 assign 的新值就失效了，那么也就白加了，导致了丢失 ++ 操作
2、尚硅谷 - 周阳讲把原因归结为写覆盖，比如 2 个线程都 use 后计算出了新值，线程 2 出了问题没来得及 assign 触发 MESI 协议，但是第一个线程正常触发 MESI 协议，但是线程 2 由于某种原因没有收到了已经变化的信号，那么第 2 个线程 assign 的新值也执行了 store-write 操作，那么第一个线程的加操作被覆盖了，导致了丢失 ++ 操作
一句话：将要 assign-store-write 的这个原子性操作，被挂起或者其他原因，没有收到其他线程的 M 消息，也就没有正常去失效自己之前将要的 assign-store-write 的新变量值，线程恢复时去更改主内存，那么就覆盖其他线程的操作。
我们看到 jvm 通过 lock 实现了 volatile 的内存屏障，但是 volatile 并不具有原子性。原因很简单，不同 CPU 依旧可以对同一个缓存行持有，一个 CPU 对同一个缓存行的修改不能让另一个 CPU 及时感知，因此出现并发冲突。线程安全还是需要用锁来保障，锁能有效的让 CPU 在同一个时刻独占某个缓存行，执行完并释放锁后，其他 CPU 才能访问该缓存行。
4、传递性规则：如果 A happens-before B，且 B happens-before C，那么 A happens-before C。
5、start 规则：如果线程 A 执行操作 ThreadB.start(),那么线程 A 的 ThreadB.start() 操作 happens-before 线程 B 中的任意操作。
6、join 规则：如果线程 A 执行操作 ThreadB.join() 并成功返回，那么线程 B 中的任意操作 happens-before 于线程 A 从 ThreadB.join() 操作成功返回。
3.5.1. 具体案例
线程之间解锁、加锁传递时，之前的写是可见的
开始前的自己可以看，结束后的别人可以看
这里主线程 (或其他线程) 得知 t2 被打断之后，读取 x 的值是修改后的，当然 while 循环中 t2 被打断后，t2 自己的读也是可以读到的。
3.6. 与 MESI 的关系
在多核 cpu 中通过缓存一致性协议保证了每个缓存中使用的共享变量的副本是一致的。
当一个 CPU 进行写入时，首先会给其它 CPU 发送 Invalid 消息，然后把当前写入的数据写入到 Store Buffer 中。然后异步在某个时刻真正的写入到 Cache 中。当前 CPU 核如果要读 Cache 中的数据，需要先扫描 Store Buffer 之后再读取 Cache。但是此时其它 CPU 核是看不到当前核的 Store Buffer 中的数据的，要等到 Store Buffer 中的数据被刷到了 Cache 之后才会触发失效操作。而当一个 CPU 核收到 Invalid 消息时，会把消息写入自身的 Invalidate Queue 中，随后异步将其设为 Invalid 状态。和 Store Buffer 不同的是，当前 CPU 核心使用 Cache 时并不扫描 Invalidate Queue 部分，所以可能会有极短时间的脏读问题。MESI 协议，可以保证缓存的一致性，但是无法保证实时性。所以我们需要通过内存屏障在执行到某些指令的时候强制刷新缓存来达到一致性。
但是 MESI 只是一种抽象的协议规范，在不同的 cpu 上都会有不同的实现，对于 x86 架构来说，store buffer 是 FIFO，写入顺序就是刷入 cache 的顺序。但是对于 ARM/Power 架构来说，store buffer 并未保证 FIFO，因此先写入 store buffer 的数据，是有可能比后写入 store buffer 的数据晚刷入 cache 的
我们再回想起来上一篇文章中 MESI 中的内容。加了 lock 前缀的指令会严格保证 MESI 协议中的数据一致性，保证对某个内存的独占使用，保证该 CPU 对应缓存行为独占，其他 CPU 的缓存行则失效。在 x86 上，任何带 lock 前缀的指令都可以可以当成一个 StoreLoad 屏障。
IA32 中对 lock 的说明是
The LOCK # signal is asserted during execution of the instruction following the lock prefix. This signal can be used in a multiprocessor system to ensure exclusive use of shared memory while LOCK # is asserted
]]> 性能调优 JVM 性能调优 并发编程专题-基础-6、CAS/2022/11/10/003-%E5%B9%B6%E5%8F%91%E7%BC%96%E7%A8%8B%E4%B8%93%E9%A2%98/%E5%B9%B6%E5%8F%91%E5%9F%BA%E7%A1%80-6%E3%80%81CAS/1. JUC 中的 CAS
1.1. 是什么
1.2. 底层原理
1.2.1. 保证可见性
1.2.2. 保证原子性
1.3. 汇编实现
1.4. synchronized 中的 CAS
1.4.1. Atomic::cmpxchg_ptr
轻量级锁加锁的时候，如果处于无锁状态，则会通过 CAS 操作将锁对象的 Mark Word 更新为指向 Lock Record 的指针，相关代码如下：
1 2 3 4 5 6 7 8 9 10
if (mark->is_neutral()) { // Anticipate successful CAS -- the ST of the displaced mark must // be visible <= the ST performed by the CAS. lock->set_displaced_header(mark); if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark)) { TEVENT (slow_enter: release stacklock) ; return ; } // Fall through to inflate() ... }
其中 CAS 操作是通过 Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark) 这段代码实现的。它有 3 个参数：
// Adding a lock prefix to an instruction on MP machine // VC++ doesn't like the lock prefix to be on a single line // so we can't insert a label after the lock prefix. // By emitting a lock prefix, we can define a label after it. #define LOCK_IF_MP(mp) __asm cmp mp, 0 \ __asm je L0 \ __asm _emit 0xF0 \ __asm L0:
**ROB（re-order buffer）：重新排序缓冲区。ROB 的存在 ROB 的目的为存储 out-of-order 的处理结果，作为 EU 的入口兼部分出口，它是乱序执行的最基本保证。当指令被传如 ROB 中，微指令流会以顺序执行的方式传入到后面的 RS，在经过 ROB 时，会占用 ROB 的一个位置，这个位置是存储微指令乱序执行处理完成时候的结果，之后经过整合会顺序写回到相应的寄存器。而微指令在经过 ROB 时候会做一些优化。（消除寄存器移动，置零指令与置一指令等）。此外对于超线程中的寄存器别名技术在此经过 RAT（寄存器别名表）进行寄存器重命名。
处理器会拷贝一段连续的 64 字节的内存段到 L1 缓存里，而不是仅仅拷贝一个单独的变量。比如 long 类型变量，1 个占用 8 个字节，那么一个缓存行就可放 8 个 long 类型的变量
现在总结一下，为了平衡 CPU 和内存的性能差异，现在 CPU 引入高速缓存：
**高速缓存 (CPU Cache)**：用于平衡 CPU 和内存的性能差异，分为 L1/L2/L3 Cache。其中 L1/L2 是 CPU 私有，L3 是所有 CPU 共享。
**缓存行 (Cache Line)**：高速缓存的最小单元，一次从内存中读取的数据大小。常用的 Intel 服务器 Cache Line 的大小通常是 64 字节。
两种写入策略。
**写直达 (Write-Through)**：每一次数据都要写入到主内存里面。
**写回 (Write-Back)**：数据写到 CPU Cache 就结束。只有当 CPU Cache 是脏数据时，才把数据写入主内存。 写回这个策略里，如果我们大量的操作，都能够命中缓存。那么大部分时间里，我们都不需要读写主内存，自然性能会比写直达的效果好很多。
1.2.2.2. 伪共享
[[【译】CPU 高速缓存原理和应用 - Strike Freedom]]
1.3. 乱序执行技术
乱序执行（Out-of-order Execution）是以乱序方式执行指令，即 CPU 允许将多条指令不按程序规定的顺序而分开发送给各相应电路单元进行处理。这样，根据各个电路单元的状态和各指令能否提前执行的具体情况分析，将能够提前执行的指令立即发送给相应电路单元予以执行，在这期间不按规定顺序执行指令；然后由 重新排列单元将各执行单元的结果按指令顺序重新排列。乱序执行的目的，就是为了 使 CPU 内部电路满负荷运转，并相应提高 CPU 运行程序的速度。
因为 MESI 规范要求变量值写入缓存行的前提条件是变量必须在缓存行中，这就要求有一个中间的 StoreBuffer 作为缓冲 (其实这是 StoreBuffer 需要存在的一个原因，主要原因还是为了避免 CPU 写入缓存行时等待其他 CPU 的 ack 消息而导致的性能下降)，否则会导致 CPU 效率下降。那么 ROB 写入到 StoreBuffer 有 2 种方式：
4.CPU1 会将 M 状态的变量立刻写回至主内存中，写回完毕之后，CPU1 会将使用状态置为（E 独享），发送消息至总线，告知其他 CPU 已经写回完毕，其他 CPU 会再此从主内存中读取变量 count 的值，读取完毕之后，也会发送消息至总线，其他 CPU 嗅探到之后将自身变量 count 置为（S 共享），自身变量的使用状态也会置为（S 共享）
MESI 失效时，缓存锁会退化到总线锁，失效的情况：
当缓存行存储的数据超过最小存储单元大小时（数据长度存储跨越多个缓存行的情况），就会导致 MESI 操作缓存行无效，导致 MESI 缓存一致性协议失效；
当 cpu0 要写数据到本地 cache的时候，如果不是 M 或者 E 状态，需要发送一个 invalidate 消息给 cpu1，只有收到 cpu1 的 acknowledgement 才能写数据到 cache 中，在这个过程中 cpu0 需要等待，这大大影响了性能。一种解决办法是在 cpu 和 cache 之间引入 store buffer，当发出 invalidate 之后直接把数据写入 store buffer。当收到 acknowledgement 之后可以把 store buffer 中的数据写入 cache。 现在的架构图是这样的： ^47f91q
Store Buffer 的确提高了 CPU 的资源利用率，不过优化了带来了新的问题。在新数据存储在 Store Buffer 里时，如果此时有一条 read 指令，若仍旧从 cache 中读取数据时，读到的是旧的数据。要解决这个问题就必须要求 CPU 读取数据时得先看 Store Buferes 里面有没有，如果有则直接读取 Store Buferes 里的值，如果没有才能读取自己缓存里面的数据，这也就是所谓的“Store Forward”。
MESI MESI 通过给每一个 Cache Line 设置一个大小为 2bit （四个状态）的状态位来保证一致性
状态描述 M（Modified）被修改的，该 Cache Line 被当前 CPU 核心修改了，和主存不一致，但是是最新的数据，可以直接使用 E（Exclusive）独占的，该 Cache Line 只有当前 CPU 核心有，而且数据和主存一样，可以直接使用 S（Shared）共享的，有多个 CPU 核心里有该 Cache Line，而且数据和主存一样，可以直接使用 I（Invalid）失效的，表示该 Cache Line 无效，需要读取数据就直接取主存中读取即可 例子 情景：假设现在存在一个 CPU 存在两个核心 core a， core b；
3.9.1. 读取数据
core a 需要读取数据 x core a 会先查看自己的缓存中是否有该数据： 如果存在，就查看 Cache Line 的状态，如果是 M，E，S 的话直接使用即可 如果不存在，或者 状态是 I ，就会向总线发起读请求 (read)，其他 CPU 核心就会监听该消息，并检查自己有没有该数据:
如果 core b 缓存中没有该数据，core a 就直接到主存中读取数据即可
如果 core b 缓存中有该数据， 状态是 E ，说明 core b 的缓存和主存一致，那么 core b 就会把该 数据发送到总线，让 core a 去获取数据，还需要把状态改为 S
如果 core b 缓存中有该数据，状态是 S ，说明 core b 的缓存和主存一致，那么 core b 就会把该 数据发送到总线，让 core a 去获取数据
如果 core b 缓存中有该数据，状态是 M，说明 core b 的缓存和主存不一致，那么 core b 需要先把数据写到主存中，把状态改为 S，分享给 core a
如果 core b 缓存中有该数据，状态是 I，core a 就直接到主存中读取数据即可
3.9.2. 写入数据
core a 需要写入数据 x
core a 会先查看自己的缓存中是否有该数据： 如果存在，并且 Cache Line 的状态为 M ，说明该数据只有在 core a 中是最新的，那么直接修改数据即可，状态不变 如果存在，并且 Cache Line 的状态为 E ，说明该数据只有在 core a 中是最新的，那么直接修改数据，然后修改状态为 M 如果存在，并且 Cache Line 的状态为 S ，说明该数据在其他核心中存在备份，那么需要发出一个 RFO (Request For Owner) 请求，它需要拥有这行数据的权限，通知到其他的 CPU 核心， 自己对该数据进行了修改， 其他核心需要把自己对应的 Cache Line 的状态改为 I ，即无效，core a 需要修改状态为 M 如果不存在或者为 Cache Line 状态为 I ，就需要先读取数据到缓存中（回到上面的读取数据流程），然后修改状态为 M ，同时发消息到总线通知其他核心将该数据状态改为 I
步骤 2、通过 CAS 尝试将 Mark Word 设置为 markOopDesc:INFLATING，标识当前锁正在膨胀中。如果 CAS 失败，说明同一时刻其它线程已经将 Mark Word 设置为 markOopDesc:INFLATING，当前线程进行自旋等待膨胀完成。
步骤 3、如果 CAS 成功，设置 monitor 的各个字段：设置 monitor 的 header 字段为 displaced mark word，owner 字段为 Lock Record，obj 字段为锁对象等；
📢 设置 ObjectMonitor 的 _owner 为拥有对象轻量级锁的线程的 Lock Record，而不是当前正在 inflate 的线程的 Lock Record，用于重量级锁竞争的判断。根本原因是因为锁对象的 Mark Word 里轻量级锁信息变成了重量级锁的信息，如果这个 CAS 操作是其他线程 (比如 B) 完成的，那么 A 是不知情的，而且 B 在获取轻量级锁时也 Blocked 了，所以干脆让 A 去处理轻量级锁膨胀后的逻辑。
步骤 4、设置锁对象头的 mark word 为重量级锁状态，指向第一步分配的 monitor 对象；
这里注意，轻量级锁膨胀成功时，会把 owner 字段设置为膨胀之前轻量级锁持有线程的栈中的 Lock Record 的指针，并在竞争时判断，具体是用在了步骤 2 的判断里。这么做的原因是，假设当前线程 A 持有锁对象的锁，线程 B 进入同步代码块，并把锁对象升级为重量级锁。但此时，线程 A 可能还在执行，并无法感知其持有锁对象的变化。因此，需要线程 B 在执行 ObjectMonitor::enter 时，将自己放入到阻塞等列等待。并需要线程 A 第二次进入、或者退出的时候对 monitor 进行一些操作，以此保证代码块的同步。
void ATTR ObjectMonitor::exit(bool not_suspended, TRAPS){ Thread * Self = THREAD ; if (THREAD != _owner) {//如果当前锁对象中的_owner没有指向当前线程 //如果_owner指向的BasicLock在当前线程栈上,那么将_owner指向当前线程 if (THREAD->is_lock_owned((address) _owner)) { // Transmute _owner from a BasicLock pointer to a Thread address. // We don't need to hold _mutex for this transition. // Non-null to Non-null is safe as long as all readers can // tolerate either flavor. assert (_recursions == 0, "invariant") ; _owner = THREAD ; _recursions = 0 ; OwnerIsThread = 1 ; } else { // NOTE: we need to handle unbalanced monitor enter/exit // in native code by throwing an exception. // TODO: Throw an IllegalMonitorStateException ? TEVENT (Exit - Throw IMSX) ; assert(false, "Non-balanced monitor enter/exit!"); if (false) { THROW(vmSymbols::java_lang_IllegalMonitorStateException()); } return; } } //如果当前，线程重入锁的次数，不为0，那么就重新走ObjectMonitor::exit，直到重入锁次数为0为止 if (_recursions != 0) { _recursions--; // this is simple recursive enter TEVENT (Inflated exit - recursive) ; return ; } ...//此处省略很多代码 for (;;) { if (Knob_ExitPolicy == 0) { OrderAccess::release_store(&_owner, (void*)NULL); //释放锁 OrderAccess::storeload(); // See if we need to wake a successor if ((intptr_t(_EntryList)|intptr_t(_cxq)) == 0 || _succ != NULL) { TEVENT(Inflated exit - simple egress); return; } TEVENT(Inflated exit - complex egress); //省略部分代码... } //省略部分代码... ObjectWaiter * w = NULL; int QMode = Knob_QMode; //根据QMode的模式判断， //如果QMode == 2则直接从_cxq挂起的线程中唤醒 if (QMode == 2 && _cxq != NULL) { w = _cxq; ExitEpilog(Self, w); return; } //省略部分代码... 省略的代码为根据QMode的不同，不同的唤醒机制 } }
从当前线程的栈中找到一个空闲的 Lock Record（即代码中的 BasicObjectLock，下文都用 Lock Record 代指），判断 Lock Record 是否空闲的依据是其 obj 字段是否为 null。注意这里是按内存地址从低往高找到最后一个可用的 Lock Record，换而言之，就是找到内存地址最高的可用 Lock Record。
获取到 Lock Record 后，首先要做的就是为其 obj 字段赋值。
判断锁对象的 mark word 是否是偏向模式，即低 3 位是否为 101。
5. CAS 将偏向线程 id 改为当前线程 id，如果当前是匿名偏向则能修改成功，否则进入锁升级的逻辑。 6. 若对象头 mark word 显示存储 thread id 为当前线程 id，表明这是一次锁重入操作，会向当前线程的栈帧中 添加一条 displaced mark word 为空的 lock record 记录（与轻量级锁记录重入记录原理相同）。 7. 若对象头 mark word 显示已存储其它 thread id，表明该锁对象已偏向其它线程，进入偏向锁撤销流程。等待 safepoint 检查偏向线程是否存活（遍历 jvm 线程栈检查），若偏向线程存活且还在执行同步代码块则进入升级轻量锁流程，否则将对象头 mark word 置为无锁 mark word，进入升级轻量级锁流程。
偏向的线程是否还在同步块中，如果不在了，则撤销偏向锁。我们回顾一下偏向锁的加锁流程：每次进入同步块（即执行 monitorenter）的时候都会以从高往低的顺序在栈中找到第一个可用的 Lock Record，将其 obj 字段指向锁对象。每次解锁（即执行 monitorexit）的时候都会将最低的一个相关 Lock Record 移除掉。所以可以通过遍历线程栈中的 Lock Record 来判断线程是否还在同步块中。
将偏向线程所有相关 Lock Record 的 Displaced Mark Word 设置为 null，然后将最高位的 Lock Record 的 Displaced Mark Word 设置为无锁状态，最高位的 Lock Record 也就是第一次获得锁时的 Lock Record（这里的第一次是指重入获取锁时的第一次），然后将对象头指向最高位的 Lock Record，这里不需要用 CAS 指令，因为是在 safepoint。 执行完后，就升级成了轻量级锁。原偏向线程的所有 Lock Record 都已经变成轻量级锁的状态。
锁释放是指线程执行完毕，退出同步代码块。偏向锁的释放并不是偏向锁的撤销，对象头还是偏向锁。most_recent->set_obj(NULL); 这就是释放偏向锁，其实啥也没干。还要把这条 LockRecord 删除掉 每次解锁（即执行 monitorexit）的时候都会将最低的一个相关 Lock Record 移除掉。
偏向锁的释放可参考 bytecodeInterpreter.cpp#1923，这里也不贴了。偏向锁的释放只要将对应 Lock Record 释放就好了，但这里的释放并不会将 mark word 里面的 thread ID 去掉，这样做是为了下一次更方便的加锁。而轻量级锁则需要将 Displaced Mark Word 替换到对象头的 mark word 中。如果 CAS 失败或者是重量级锁则进入到 InterpreterRuntime::monitorexit 方法中。
4.1.8. 锁重入
该线程 ID 是自己的,则表示可重入,直接可以获取 (此时在自己的线程栈中继续生成一条新的 Lock Record)
JVM 在当前线程的栈帧中创建 Lock Reocrd，将内部 obj （ptr_to_obj）指针指向锁对像。然后构造一个无锁状态的 Mark Word(相当于复制无锁状态的 Mark Word 到锁记录中)，并将 lock record 中的 Displaced Mark Word 指向它。（Displaced Mark Word，供解锁时恢复锁对象对象头）
线程尝试使用 CAS 将对象头中的 Mark Word 中的 ptr_to_lock_record(指向栈中锁记录的指针) 替换为 上面第一步刚在栈中创建的 Lock Reocrd 的指针。如果成功则获得锁
CAS 失败时判断检查已获取轻量级锁线程是否为自己（遍历栈帧查找其它 obj* 指向同个对象且 mark word 不为空的 lock record），如果是则代表当前为一次锁重入，就将当前 lock record 的 mark word （displaced mark word）置为 null(上面第一步设置的)，即当前 lock record 即作为一个计数器使用，结束。
若 CAS 失败且当前线程栈帧中不存在其它指向该锁对象的 lock record，说明存在其它线程竞争，锁膨胀至重量级锁。
publicintsize() { // Try a few times to get accurate count. On failure due to // continuous async changes in table, resort to locking. final Segment<K,V>[] segments = this.segments; int size; boolean overflow; // true if size overflows 32 bits long sum; // sum of modCounts longlast=0L; // previous sum intretries= -1; // first iteration isn't retry try { for (;;) { //当第5次走到这个地方时，会将整个Segment[]的所有Segment对象锁住 if (retries++ == RETRIES_BEFORE_LOCK) { for (intj=0; j < segments.length; ++j) ensureSegment(j).lock(); // force creation } sum = 0L; size = 0; overflow = false; for (intj=0; j < segments.length; ++j) { Segment<K,V> seg = segmentAt(segments, j); if (seg != null) { //累加所有Segment的操作次数 sum += seg.modCount; intc= seg.count; //累加所有segment中的元素个数 size+=c if (c < 0 || (size += c) < 0) overflow = true; } } //当这次累加值和上一次累加值一样，证明没有进行新的增删改操作，返回sum //第一次last为0，如果有元素的话，这个for循环最少循环两次的 if (sum == last) break; //记录累加的值 last = sum; } } finally { //如果之前有锁住，解锁 if (retries > RETRIES_BEFORE_LOCK) { for (intj=0; j < segments.length; ++j) segmentAt(segments, j).unlock(); } } //溢出，返回int的最大值，否则返回累加的size return overflow ? Integer.MAX_VALUE : size; }
在反序列化的过程中，如果接收方为对象加载了一个类，如果该对象的 serialVersionUID 与对应持久化时的类不同，那么反序列化的过程中将会导致 InvalidClassException 异常。例如，在之前反序列化的例子中，我们故意将 User 类的 serialVersionUID 改为 2L，如：
1
privatestaticfinallongserialVersionUID=2L;
那么此时，在反序例化时就会导致异常，如下：
1 2 3 4 5 6 7 8 9
java.io.InvalidClassException: cn.wudimanong.serializable.User; local classincompatible: stream classdescserialVersionUID=1, local classserialVersionUID = 2 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:687) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1880) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1746) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2037) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428) at cn.wudimanong.serializable.SerializableTest.readObj(SerializableTest.java:31) at cn.wudimanong.serializable.SerializableTest.main(SerializableTest.java:44)
* threshold of 0.75, although with a large variance because of * resizing granularity. Ignoring variance, the expected * occurrences of list size k are (exp(-0.5) * pow(0.5, k) / * factorial(k)). The first values are: * * 0: 0.60653066 * 1: 0.30326533 * 2: 0.07581633 * 3: 0.01263606 * 4: 0.00157952 * 5: 0.00015795 * 6: 0.00001316 * 7: 0.00000094 * 8: 0.00000006 * more: less than 1 in ten million
final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) { //申明tab 和 p 用于操作原数组和结点 Node<K,V>[] tab; Node<K,V> p; int n, i; //如果原数组是空或者原数组的长度等于0，那么通过resize()方法进行创建初始化 if ((tab = table) == null || (n = tab.length) == 0) //获取到创建后数组的长度n n = (tab = resize()).length;
/** * Returns the number of elements in this collection. If this collection * contains more than <tt>Integer.MAX_VALUE</tt> elements, returns * <tt>Integer.MAX_VALUE</tt>. * *@return the number of elements in this collection */intsize();
业务开发时常常要对 List 做切片处理，即取出其中部分元素构成一个新的 List，我们通常会想到使用 List.subList 方法。但，和 Arrays.asList 的问题类似，List.subList 返回的子 List 不是一个普通的 ArrayList。这个子 List 可以认为是原始 List 的视图，会和原始 List 相互影响。如果不注意，很可能会因此产生 OOM 问题。接下来，我们就一起分析下其中的坑。
如下代码所示，定义一个名为 data 的静态 List 来存放 Integer 的 List，也就是说 data 的成员本身是包含了多个数字的 List。循环 1000 次，每次都从一个具有 10 万个 Integer 的 List 中，使用 subList 方法获得一个只包含一个数字的子 List，并把这个子 List 加入 data 变量：
1 2 3 4 5 6 7 8 9 10 11 12 13
privatestatic List<List<Integer>> data = newArrayList<>();
这个时间复杂度的分析方法比较难想到。我把问题分解一下，先来看这样一个问题，如果链表里有 n 个结点，会有多少级索引呢？
按照我们刚才讲的，每两个结点会抽出一个结点作为上一级索引的结点，那第一级索引的结点个数大约就是 n/2，第二级索引的结点个数大约就是 n/4，第三级索引的结点个数大约就是 n/8，依次类推，也就是说，**第 k 级索引的结点个数是第 k-1 级索引的结点个数的 1/2，那第 k 级索引结点的个数就是 n/(2 的k 次方)。
假设索引有 h 级，最高级的索引有 2 个结点。通过上面的公式，我们可以得到 n/(2h)=2，从而求得 h=log2n-1。如果包含原始链表这一层，整个跳表的高度就是 log2n。我们在跳表中查询某个数据的时候，如果每一层都要遍历 m 个结点，那在跳表中查询一个数据的时间复杂度就是 O(m*logn)。
那这个 m 的值是多少呢？按照前面这种索引结构，我们每一级索引都最多只需要遍历 3 个结点，也就是说 m=3，为什么是 3 呢？我来解释一下。
假设我们要查找的数据是 x，在第 k 级索引中，我们遍历到 y 结点之后，发现 x 大于 y，小于后面的结点 z，所以我们通过 y 的 down 指针，从第 k 级索引下降到第 k-1 级索引。在第 k-1 级索引中，y 和 z 之间只有 3 个结点（包含 y 和 z），所以，我们在 K-1 级索引中最多只需要遍历 3 个结点，依次类推，每一级索引都最多只需要遍历 3 个结点。
/* 对数组中，从lo到mid为一组，从mid+1到hi为一组，对这两组数据进行归并 */ privatestaticvoidmerge(Comparable[] a, int lo, int mid, int hi) { //定义三个指针 int i=lo; int p1=lo; int p2=mid+1;
//对数组a中，从索引 lo到索引 hi之间的元素进行分组，并返回分组界限对应的索引 publicstaticintpartition(Comparable[] a, int lo, int hi) { //确定分界值 Comparablekey= a[lo]; //定义两个指针，分别指向待切分元素的最小索引处和最大索引处的下一个位置 int left=lo; int right=hi+1;
//切分 while(true){ //先从右往左扫描，移动right指针，找到一个比分界值小的元素，停止 while(less(key,a[--right])){ if (right==lo){ break; } }
//再从左往右扫描，移动left指针，找到一个比分界值大的元素，停止 while(less(a[++left],key)){ if (left==hi){ break; } } //判断 left>=right,如果是，则证明元素扫描完毕，结束循环，如果不是，则交换元素即可 if (left>=right){ break; }else{ exch(a,left,right); } }
但是，有利就有弊。链表要想随机访问第 k 个元素，就没有数组那么高效了。因为链表中的数据并非连续存储的，所以无法像数组那样，根据首地址和下标，通过寻址公式就能直接计算出对应的内存地址，而是需要根据指针一个结点一个结点地依次遍历，直到找到相应的结点。
你可以把链表想象成一个队伍，队伍中的每个人都只知道自己后面的人是谁，所以当我们希望知道排在第 k 位的人是谁的时候，我们就需要从第一个人开始，一个一个地往下数。所以，链表随机访问的性能没有数组好，需要 O(n) 的时间复杂度。
5. 链表VS数组
数组简单易用，在实现上使用的是连续的内存空间，可以借助 CPU 的缓存机制，预读数组中的数据，所以访问效率更高。而链表在内存中并不是连续存储，所以对 CPU 缓存不友好，没办法有效预读。
数组的缺点是大小固定，一经声明就要占用整块连续内存空间。如果声明的数组过大，系统可能没有足够的连续内存空间分配给它，导致“内存不足（out of memory）”。如果声明的数组过小，则可能出现不够用的情况。这时只能再申请一个更大的内存空间，把原数组拷贝进去，非常费时。链表本身没有大小的限制，天然地支持动态扩容，我觉得这也是它与数组最大的区别。
如果数组中的数据是有序的，我们在某个位置插入一个新的元素时，就必须按照刚才的方法搬移 k 之后的数据。但是，如果数组中存储的数据并没有任何规律，数组只是被当作一个存储数据的集合。在这种情况下，如果要将某个数组插入到第 k 个位置，为了避免大规模的数据搬移，我们还有一个简单的办法就是，直接将第 k 位的数据搬移到数组元素的最后，把新的元素直接放入第 k 个位置。
KMP 算法包含两部分，第一部分是构建 next 数组，第二部分才是借助 next 数组匹配。所以，关于时间复杂度，我们要分别从这两部分来分析。
构建 next 数组，j 从 1 开始一直增加到 m，而 k 并不是每次 for 循环都会增加，所以，k 累积增加的值肯定小于 m。而 while 循环里 k=next[k]，实际上是在减小 k 的值，k 累积都没有增加超过 m，所以 while 循环里面 k=next[k] 总的执行次数也不可能超过 m。因此，next 数组计算的时间复杂度是 O(m)。
我们再来分析第二部分的时间复杂度。分析的方法是类似的。
i 从 0 循环增长到 n-1，j 的增长量不可能超过 i，所以肯定小于 n。而 while 循环中的那条语句 j=next[j]+1，不会让 j 增长的，那有没有可能让 j 不变呢？也没有可能。因为 next[j] 的值肯定小于 j，所以 while 循环中的这条语句实际上也是在让 j 的值减少。而 j 总共增长的量都不会超过 n，那减少的量也不可能超过 n，所以 while 循环中的这条语句总的执行次数也不会超过 n，所以这部分的时间复杂度是 O(n)。
使用onto之后, 后面会跟3个参数，可以更精确地变基 $ git rebase –onto base from to 命令的意义使用(from, to]所指定的范围内的所有commit在base这个commit之上进行重建，相当于找到from和to公共节点之后，to分支所做的内容，在base上重演.
接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？ 于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。 这类系统，诸如 CVS、Subversion等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 多年以来，这已成为版本控制系统的标准做法。
^17d8bq
这里的MenuComponent定义为抽象类，因为有一些共有的属性和行为要在该类中实现，Menu和MenuItem类就可以只覆盖自己感兴趣的方法，而不用搭理不需要或者不感兴趣的方法，举例来说，
1. 环境类 (SalesMan)
，可以得到以下结果：
](https://www.bilibili.com/video/BV1pY4y1A7Pv/?spm_id_from=333.337.search-card.all.click&vd_source=c5b2d0d7bc377c0c35dbc251d95cf204!%5B%5D(https://raw.githubusercontent.com/TaylorLuo/typora-imgs/master/img20221216101945.png)){kind=link}
