qq_51967234的博客

为什么我们要对频繁full gc的情况进行处理---》频繁full gc会导致stw，影响用户体验。在一个bean中有一个List的成员变量，在代码中多次add，导致他变得很大。查看是否有大对象---》发现有很多XXXDTO对象，放在List数组中，且占了绝大多数内存。如果频繁full gc 会报警，公司有自己的监控平台，可以查看full gc的情况。在代码中做查询的时候没有做好条件过滤及分页，导致数据库查询了大量的数据。如果公司没有自己的监控平台，可以自己去机器上查看 gc 日志。

CPU利用率是来描述CPU的使用情况的，表明了一段时间内CPU被占用的情况。测试人员在压测的时候，会对应用进行测试，这个时候会查看cpu、内存、load、rt、qps等指标。上图 pid为1893的进程cpu占用率181.7%，基本可以定位到是由这个进程引起的cpu飙高。可以看到 BeanValidator.java的第30行代码可能是存在问题的。可以看到在1893进程中，ID为4519的线程占用cpu最高，如果代码没问题，可能是机器遇到瓶颈了，这个时候要考虑扩容了。

MySQL默认的处理方式是自动检测到死锁后，其中一个事务会被选择为"牺牲者"并回滚，以解除死锁。被选择的事务会收到一个Deadlock Detected异常，然后回滚该事务，释放相关的资源，允许其他事务继续执行。当死锁发生时，MySQL会选择其中一个事务进行回滚，以解除死锁，并且会记录相关的死锁信息，可通过查看错误日志或使用SHOW ENGINE INNODB STATUS命令来获取死锁信息。可以分析得出被死锁具体的表和sql语句了， 解决通过查看具体的线程id，kill 掉，手动去补偿数据。

如果单纯对一个数据库进行select，仅仅考虑select的话，select天然具有幂等性。但是如果涉及主从同步的话，就会存在幂等性的问题：用户第一次下单，先从从库查，没有，在主库中插入一条订单，此时用户手抖再次下单，从从库查（但是主库还没来得及同步从库）没有，用户重复下单成功，导致出了问题，如果关键读从主库读就不会有问题了。

2. 本地事务为什么在一阶段提交:为了提高性能，AT模式基于2PC的，但2PC的一阶段并不会真正提交本地事务，也就意味着一直持有资源不释放，性能较差，但AT模式在一阶段提交了本地事务，其他本地事务就可以执行，但全局锁还没有释放，同时还有undolog image的记录，来保证后续有异常仍然能够进行事务回滚，提高性能。4. AT模式的隔离级别:读未提交，因为当一阶段本地事务提交之后，其他的分布式事务已经可以看到提交后的数据，但因为有全局锁的存在，此时全局锁还没有释放，只能读到数据不能写数据。

强制线程每次读取时都从主内存中获取，每次写入时都写入主内存，确保变量的可见性。仅用于声明变量，确保在多线程环境中的可见性，使所有线程都能看到最新的变量值。通过保证变量的可见性，提供了一定的线程安全保障。它还可以用于方法、初始化块和内部类。变量在内存中有一个存储位置，所有实例共享这一个存储位置。关键字用于创建类级别的变量或方法，所有类的实例共享同一个。不保证原子性，因此在复杂操作中可能不足以保证线程安全。由于所有实例共享一个变量副本，因此性能较高。可能影响性能，因为每次读写都需要访问主内存。

在使用分布式锁的时候,习惯性的尽量缩小同步代码块的范围。但是如果数据库隔离级别是可重复读,这种情况下不要把分布式锁加在@Transactional注解的事务方法内部。因为可能会出现这种情况：

在多线程并发的场景下，JavaSynchronized/Reentrantlock锁能够实现同⼀个JVM进程内多线程并发的安全性，但⽆法保证多个JVM进程实例构成的集群环境在多线程下的安全性。在⼀些业务场景下需要引⼊分布式锁。

发生在初始化阶段，从节点会主动向主节点发出一个同步请求，之后主节点会生成一份当前数据的快照给从节点，从节点在收到数据进行加载后，会完成全量复制。主是主服务器，从是从服务器，主服务器(master ）的数据如果更新了也会同步到从服务器(slave)，一个主服务器可以搭配很多个从服务器，，每一次Master（主）结点发生数据变更之后，会把变化的增量数据同步给从节点，增量复制是通过维护offset复制偏移量来实现的。Redis主从复制包括。

当客户端在Redis的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节点依旧可以正常对外提供修改服务，所以Redis满足「可用性」。，最终从节点的状态会和主节点的状态将保持一致。在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据的「一致性」将无法满足，因为两个分布式节点的数据不再保持一致。分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有网络断开的风险，这个网络断开的场景的专业词汇叫着「网络分区」。

就是说，虽然binlog里面会针对于一个事务里的sql进行完整的记录也会记录事务的开启提交状态，但是呢这都是逻辑层面的，比如说记录一条sql (statement格式)，比如说记录xx行数据+1，xx行数据-1（row格式)，但是我们思考一个问题，mysql真实的数据存储是通过数据页的形式记录在磁盘的，也就是说，一个事务涉及到很多sql，一条sql语句可能涉及到很多数据页的变更，只通过binlog我们是无法判断一个事务的修改到底有没有真正落实到磁盘上的，为什么呢?一定是和正确答案一字不落的吗?

token其实也是一样的，是当客户端第一次发起请求时，服务器通过签名生成的一连串字符串，这个字符串只有服务器自己明白什么意思，别的人拿到也是一头雾水，甚至连客户端自己都不知道是什么意思。客户端再次发送请求时，一般会将token发在自己的请求头中，服务端收到请求后，会先去验证客户端发送的token是否与自己签发的token一致，如果一致则响应请求，如果不一致则拒绝请求。当然如果你如果只想做个系统自娱自乐，我就自己用，并不想让别用，那么通过数据库查询的方式完全是可以的，但是，一个公司做个项目不可能自娱自乐吧？

唯一作用就是配合引用队列来监控引用的对象是否被加入到引用队列中，也就是可以准确的让我们知晓对象何时被回收。，也就是说在JVM抛出OutOfMemoryError之前，会去清理软引用对象，适合用在内存敏感的场景。，ThreadLocal中的 key 就用到了弱引用，适合用在内存敏感的场景。Java根据其生命周期的长短将引用类型又分为强引用、软引用、弱引用、虚引用。虚引用：如果一个对象仅持有虚引用，它就和没有任何引用一样，强引用：就是我们平时 new一个对象的引用。弱引用：比软引用还短，在GC的时候，

总体来说，Java程序的启动涉及了类加载、链接、初始化等多个步骤。当你运行Java程序时，Java虚拟机(JVM）会加载字节码文件。JVM通过类加载器(Class Loader）来加载字节码文件，将其转换为运行时的Java类。JVM会在加载和初始化完主类后寻找main方法，main方法是Java程序的入口点。一旦main方法被找到，JVM会执行main方法中的代码，从而启动Java程序的执行。在链接阶段，JVM将加载的类与它们引用的其他类和库进行链接。编译成功后，将在相同的目录中生成字节码文件。

因此我们通过索引查找数据数据实际上是在索引的B+树中先找到对应的主键，然后根据主键再去主键索引的B+树的叶子结点中找到完整数据，最后返回。所以虽然是两个索引树，但实际上是同一行数据，必须全部锁住。索引还是普通索引，它们的叶子结点中存储的数据都不完整，其中只是存储了作为索引并且排序好的列数据以及对应的主键值。列的唯一索引，最终定位到主键值为。的数据，最终拿到完整的行数据。对数据进行查询，会先用到。，然后再到主键索引中查询。

然后NameServer会每隔10s运行一个任务，去检查一下各个Broker的最近一次心跳时间，如果某个Broker超过120s都没发送心跳了，那么就认为这个Broker已经挂掉了。Broker会每隔30s给所有的NameServer发送心跳，告诉每个NameServer自己目前还活着。Broker会跟每个NameServer都建立一个TCP长连接，然后定时通过TCP长连接发送心跳请求过去。

（4）发送方根据本地事务执行结果向服务端提交二次确认（Commit 或是 Rollback），服务端收到Commit 状态则将半事务消息标记为可投递，订阅方最终将收到该消息；由于消息为半事务消息，在未收到生产者对该消息的二次确认前，此消息被标记成“暂不能投递”状态。（1）在断网或者是应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达服务端，经过固定时间后服务端将对该消息发起消息回查。（3） 发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行操作。

加锁（400 ms） 超时直接放弃 并发先读后写场景 必须要加锁 为什么超时直接放弃？---》假设整个流程要300ms，总不能一直干耗着，后面的线程就不用来走这个逻辑了。查redis没有才继续往下 double check（单例模式）

（仅 Web 应用可用） : 每一次来自新 session 的 HTTP 请求都会产生一个新的 bean（会话 bean），该 bean 仅在当前 HTTP session 内有效。（仅 Web 应用可用）: 每一次 HTTP 请求都会产生一个新的 bean（请求 bean），该 bean 仅在当前 HTTP request 内有效。Spring 中的 bean 默认都是单例的，是对单例设计模式的应用。，每次获取都会创建一个新的 bean 实例。两次，得到的是不同的 Bean 实例。

先从老年代 freelist（空闲链表）申请一块空间，然后在这一块空间中就可以通过指针加法（bump thepointer）来分配内存，这样对freelist竞争也少了，分配空间也快了。可以看到和TLAB很像，PLAB即 Promotion Local Allocation Buffers。大致就是上图这么个思想，每个线程先申请一块作为PLAB，然后在这一块内存里面分配晋升的对象。在多线程并行执行YGC时，可能有很多对象需要晋升到老年代，此时老年代的指针就"热"起来了，于是搞了个PLAB。