之前数据库工具一直使用的是 Navicat，最近不知道为啥老是闪退，忍不了换个工具，在同事的推荐下开始用了 DataGrip，不得不说 JetBrains 出品必是精品，真香。



# DataGrip 2024.3.3

## 下载破解包
链接：https://pan.quark.cn/s/b080b0383726

## 解压

将破解包下载以后，进行解压，展示以下目录，根据不同系统，找到对应解压包目录点进去

![image.png](/static/img/7ad216b300ef80d1face0ef1f7787fcf.image.webp)

## 目录

我得是Mac，右键点击Mac目录，然后选中 `新建位于文件夹位置的终端标签页`

![image.png](/static/img/865dfafbb12a9ebf8f617fac6f019c83.image.webp)


## 执行脚本
启动脚本

```sh
sudo bash datagrip.sh
```
提示 `Success! Activate idea to 2099` 即为成功


这版的破解要简单的多，激活日期到2099年12月31，完美！

![image.png](/static/img/4e9a55c3bbe3bacc684c28705fbf8b81.image.webp)

Mac/Win DataGrip 2024.3.3 破解

在排查生产日志的时候，发现 RocketMQ 的消费端的日志没有输出 traceId, 导致链路查询无法衔接，通过查看当前项目架构底层的实现，发现原来是没有处理过异步的链路日志

为了查询更便捷，对此架构进行优化，实现完整版的全链路的日志ID记录



# 全链路日志处理

在 SpringBoot 中，MDC（Mapped Diagnostic Context）是最常见的日志上下文关联方式。

其实现原理就是在请求链路上添加 traceId 到 MDC，在请求链路结束时清除 traceId。

MDC（Mapped Diagnostic Context）

> 是SLF4J提供的一个线程安全的诊断上下文工具。它允许开发者在同一线程上下文中存储多个键值对信息，这些信息可以自动附加到日志输出中，实现日志的上下文关联。


TraceId（分布式系统中用于唯请求全链路的唯一标识符）

> 通过 traceId，可以将一个请求在不同服务、不同节点、不同线程中的日志串联起来，形成完整的调用链路，方便快速定位问题、分析性能瓶颈或监控系统行为。


## Http 处理

在 SpringMVC 中对于 http 的处理，最常用的是 `HandlerInterceptor` 接口进行实现，在接口处理前存储到 MDC，在接口的后置处理中清空 MDC 上下文，防止内存泄漏

```java
public class MdcHandlerInterceptor implements HandlerInterceptor {

 @Override
 public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
 // 解析token，获取用户唯一标识
 String userId = "123";

 // 接口地址
 String url = request.getRequestURI();

 // 日志处理
 String traceId = request.getHeader(MdcTraceContext.TRACE_HEADER_KEY);
 MdcTraceContext.initTraceId(userId, url, traceId);
 return HandlerInterceptor.super.preHandle(request, response, handler);
 }

 @Override
 public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
 MdcTraceContext.clearTraceId();
 }
}

```

在 WebMvcConfig 中添加上拦截器才可生效

```java
@Configuration
public class MeWebMvcConfig extends WebMvcConfigurationSupport {

 @Override
 protected void addInterceptors(InterceptorRegistry registry) {
 registry.addInterceptor(new MdcHandlerInterceptor());
 }
}
```

MDC 的上下文内容，可以通过 MdcTraceContext 进行获取和设置

> 看过好多方案，除了定义 MDC 以外还会自己存储一份 ThreadLocal，其实从 MDC 底层来看，MDC 就是 ThreadLocal，所以 MDC 的设置和获取，与自定义 ThreadLocal 没有任何区别，没有必要使用 ThreadLocal 在浪费内存存储一份 traceId。

TraceId 可任意组成，最好带有唯一的识别作用

> 此处 traceId 的构成是使用用户的唯一标识、接口请求的地址和当前请求的唯一标识，这样在日志中，就可以通过不同内容对 traceId 进行链路追踪，方便快速定位问题。

```java
public class MdcTraceContext {

 /**
 * logback.xml 中全链路标识的占位符
 */
 public static final String TRACE_ID_PATTERN = "traceId";

 /**
 * 请求头的链路Key
 */
 public static final String TRACE_HEADER_KEY = "X-Requested-Id";

 /**
 * 当前操作人的唯一标识
 */
 public static final String $userId = "$userId";

 /**
 * 请求url
 */
 public static final String $url = "$url";

 /**
 * 当前请求的唯一标识
 *
 * 前端添加到请求头中 or 网关生成的uuid 
 */
 public static final String $requestId = "$requestId";

 /**
 * 链路ID
 */
 public static String TRACE_ID = "<" + $userId + "> <" + $url + "> <" + $requestId + ">";


 /**
 * 初始化TraceId
 */
 public static void initTraceId(String userId, String url, String requestId) {
 String traceId = TRACE_ID.replace($userId, StringUtils.isEmpty(userId) ? "" : userId)
 .replace($url, StringUtils.isEmpty(url) ? "" : url)
 .replace($requestId, StringUtils.isEmpty(requestId) ? "" : requestId);
 MDC.put(TRACE_ID_PATTERN, traceId);
 }

 /**
 * 初始化TraceId
 */
 public static void initTraceId(String traceId) {
 MDC.put(TRACE_ID_PATTERN, traceId);
 }

 /**
 * 获取当前TraceId
 */
 public static String getTraceId() {
 return MDC.get(TRACE_ID_PATTERN);
 }

 /**
 * 清除TraceId
 */
 public static void clearTraceId() {
 MDC.remove(TRACE_ID_PATTERN);
 }

 /**
 * 清除底层数据
 */
 public static void clear() {
 MDC.clear();
 }
}

```

其中 logback.xml 的模板配置需要生效必要设置环境变量，以下提供了dev环境的配置 `sppring.profiles.active = dev`，可根据需要自行配置

```xml
<?xml version="1.0" encoding="UTF-8"?>

<configuration>
 
 <property name="log.path" value="log"/>
 <property name="log.maxHistory" value="15"/>
 <property name="log.colorPattern" value="%magenta(%d{yyyy-MM-dd HH:mm:ss}) %highlight(%-5level) %boldCyan(%X{traceId}) %yellow(%thread) %green(%logger{50}) %msg%n"/>
 <property name="log.pattern" value="%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %X{traceId} %thread %logger{50} %msg%n"/>

 
 <springProfile name="dev">
 
 <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
 <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
 <level>DEBUG</level>
 </filter>
 <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
 <FileNamePattern>${log.path}/info.%d{yyyy-MM-dd}.log</FileNamePattern>
 </rollingPolicy>
 <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
 <pattern>${log.colorPattern}</pattern>
 </encoder>
 </appender>

 
 <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
 <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
 <level>DEBUG</level>
 </filter>
 <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
 <pattern>${log.colorPattern}</pattern>
 </encoder>
 </appender>

 
 <logger name="code72" level="DEBUG" additivity="false">
 <appender-ref ref="STDOUT"/>
 <appender-ref ref="FILE"/>
 </logger>

 
 <root level="INFO">
 <appender-ref ref="STDOUT"/>
 <appender-ref ref="FILE"/>
 </root>
 </springProfile>

</configuration>
```

以上内容就实现了Htt请求处理的全链路日志追踪，接下来还有分布式微服务下的处理


## Feign 微服务调用处理

在 Feign 中，对于异步处理的处理，也是通过拦截器进行实现，在请求头中添加上traceId，下一个微服务种即可从执行上面的 Http 处理，从请求头获取 traceId 进行链路追踪。

```java
@Slf4j
@Component
public class MdcRequestInterceptor extends MdcTraceContext implements RequestInterceptor {

 /**
 * Called for every request. Add data using methods on the supplied {@link RequestTemplate}.
 *
 * @param template
 */
 @Override
 public void apply(RequestTemplate template) {
 if(StringUtils.isNotBlank(getTraceId())){
 template.header(TRACE_HEADER_KEY, getTraceId());
 }else{
 // 本次请求没有traceId，
 log.debug("This request does not have a traceId!");
 }
 }
}
```

## RocketMQ 生产消费端处理

在 RocketMQ 中，需要在发送消息与消费消息的时候添加钩子进行处理，目前在源码中添加钩子的入口不太好找，需要对源码有一定的了解，要从生产者 `DefaultMQProducer` 与消费者 `DefaultMQPushConsumer` 进行拦截处理，具体代码如下：

```java
@Slf4j
@Component
public class MdcApplicationRunner implements ApplicationContextAware, ApplicationRunner {

 private ApplicationContext applicationContext;

 @Override
 public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
 this.applicationContext = applicationContext;
 }

 /**
 * Callback used to run the bean.
 *
 * @param args incoming application arguments
 * @throws Exception on error
 */
 @Override
 public void run(ApplicationArguments args) throws Exception {
 // 注册生产者消息hook
 registerSendMessageHook();
 // 注册消费者消息hook
 registerConsumeMessageHook();
 }

 /**
 * 注册生产者消息hook
 */
 private void registerSendMessageHook(){
 DefaultMQProducer defaultMQProducer = applicationContext.getBean(DefaultMQProducer.class);
 defaultMQProducer.getDefaultMQProducerImpl().registerSendMessageHook(new MdcSendMessageHook());
 log.info("DefaultMQProducer #registerSendMessageHook Success.");
 }

 /**
 * 注册消费者消息hook
 */
 private void registerConsumeMessageHook(){
 Map<String, DefaultRocketMQListenerContainer> beansOfType = applicationContext.getBeansOfType(DefaultRocketMQListenerContainer.class);
 for (DefaultRocketMQListenerContainer defaultRocketMQListenerContainer : beansOfType.values()) {
 defaultRocketMQListenerContainer.getConsumer().getDefaultMQPushConsumerImpl().registerConsumeMessageHook(new MdcConsumeMessageHook());
 log.info("{}:DefaultMQPushConsumer #registerConsumeMessageHook Success.", defaultRocketMQListenerContainer.getRocketMQListener().getClass().getSimpleName());
 }
 }
}
```

::: important 版本兼容问题
对于 RocketMQ 的配置，此处我是基于4.9.3版本的调整，在源码 5.1.0 的版本测试，对于其他版本具体需要对查看源码测试核验
:::


### 源码解读

对于 `DefaultRocketMQListenerContainer` 对象，是一个mq监听容器，每个容器对象都是由 `@RocketMQMessageListener` 注释的消费端生成的，由 Spring 容器管理。

![RocketMQMessageListener加载的源码](/assets/image/RocketMQMessageListener%E5%8A%A0%E8%BD%BD%E7%9A%84%E6%BA%90%E7%A0%81.png)
![RocketMQMessageListener注册的源码](/assets/image/RocketMQMessageListener%E6%B3%A8%E5%86%8C%E7%9A%84%E6%BA%90%E7%A0%81.png)


在容器内部，创建 `DefaultMQPushConsumer` 对象，也就是每个容器都会有一个 `DefaultMQPushConsumer` 对象，所以上述的代码实现中是获取的 `Map<String, DefaultRocketMQListenerContainer>`,然后对每个容器得 `DefaultMQPushConsumer` 都进行添加钩子处理。

![DefaultMQPushConsumer创建对象的源码](/assets/image/DefaultMQPushConsumer%E5%88%9B%E5%BB%BA%E5%AF%B9%E8%B1%A1%E7%9A%84%E6%BA%90%E7%A0%81.png)


### 生产者钩子

在发送消息前，从请求的本地线程中获取到traceId，并设置到消息的 Property 属性中即可，保证 traceId 会与消息一起传递

```java
@Slf4j
public class MdcSendMessageHook extends MdcTraceContext implements SendMessageHook {

 @Override
 public String hookName() {
 return MdcSendMessageHook.log.getName();
 }

 @Override
 public void sendMessageBefore(SendMessageContext context) {
 // 从MDC获取TraceId
 if (StringUtils.isNotEmpty(getTraceId())) {
 context.getMessage().putUserProperty(TRACE_HEADER_KEY, getTraceId());
 }
 }

 @Override
 public void sendMessageAfter(SendMessageContext context) {
 // 无需处理
 }
}
```

### 消费者钩子

消费者钩子，在消费消息前，从消息的 Property 中获取到 traceId，并设置到 MDC 的本地线程中，注意消息处理完成后，需要清除 MDC 的本地线程，保证线程池中的线程不会影响其他线程的链路追踪。

```java
@Slf4j
public class MdcConsumeMessageHook extends MdcTraceContext implements ConsumeMessageHook {

 @Override
 public String hookName() {
 return MdcConsumeMessageHook.class.getName();
 }

 @Override
 public void consumeMessageBefore(ConsumeMessageContext context) {
 List<MessageExt> msgList = context.getMsgList();
 if (!msgList.isEmpty()) {
 // MDC设置TraceId
 initTraceId(msgList.get(0).getProperty(TRACE_HEADER_KEY));
 }
 }

 @Override
 public void consumeMessageAfter(ConsumeMessageContext context) {
 // 清除MDC的TraceId
 clear();
 }
}

```

::: warning clear()
对于异步执行的线程，当执行完成时，需要执行 `clear()` 方法清除全部缓存信息。
:::

## JUC线程池处理

对于线程池 ThreadPoolExecutor，核心问题在于子线程无法自动获取父线程的MDC内容。

::: tip 解决方案
使用 **装饰器模式** 包装任务，封装 `Runnable` 或 `Callable`，在任务执行前将父线程的 traceId 传递到子线程的 MDC 中，执行后再清理。
:::

### 装饰 Callable

```java
@Slf4j
public class MdcCallable<V> extends MdcTraceContext implements Callable<V> {

 private Callable<V> callable;
 private Map<String, String> parentMdc;

 public MdcCallable(Callable<V> callable) {
 this.callable = callable;
 // 捕获父线程的 MDC
 this.parentMdc = MDC.getCopyOfContextMap();
 }

 /**
 * Computes a result, or throws an exception if unable to do so.
 *
 * @return computed result
 * @throws Exception if unable to compute a result
 */
 @Override
 public V call() throws Exception {
 if (parentMdc != null) {
 // 将 MDC 传递给子线程
 MDC.setContextMap(parentMdc);
 parentMdc.clear();
 parentMdc = null;
 }
 try {
 V call = callable.call();
 callable = null;
 return call;
 } finally {
 // 清理子线程的 MDC，避免内存泄漏
 clear();
 }
 }
}
```
### 装饰 Runnable

```java
@Slf4j
public class MdcRunnable extends MdcTraceContext implements Runnable {

 private Runnable runnable;
 private Map<String, String> parentMdc;

 public MdcRunnable(Runnable runnable) {
 this.runnable = runnable;
 // 捕获父线程的 MDC
 this.parentMdc = MDC.getCopyOfContextMap();
 }

 @Override
 public void run() {
 if (parentMdc != null) {
 // 将 MDC 传递给子线程
 MDC.setContextMap(parentMdc);
 parentMdc.clear();
 parentMdc = null;
 }
 try {
 runnable.run();
 runnable = null;
 } finally {
 // 清理子线程的 MDC，避免内存泄漏
 clear();
 }
 }
}
```

测试示例：

```java
public void test(){
 ExecutorService executorService = Executors.newFixedThreadPool(50);
 for (int i = 0; i < 10; i++) {
 int finalI = i;
 executorService.submit(new MdcRunnable(() -> log.info("测试 - " + finalI)));
 executorService.submit(new MdcCallable<>(() -> {
 log.info("测试 - " + finalI);
 return "测试 - " + finalI;
 }));
 }
}
```


## Spring异步线程处理

Spring 默认的线程池同样存在MDC传递的问题。

::: tip 解决方案
为了确保MDC的上下文能够传递到异步线程，在自定义异步线程池的同时，添加 `TaskDecorator` 装饰处理，
:::

```java
@Configuration
@EnableAsync
public class AsyncConfig extends AsyncConfigurerSupport {

 @Override
 public Executor getAsyncExecutor() {
 ThreadPoolTaskExecutor threadPoolTaskExecutor = new ThreadPoolTaskExecutor();
 //线程核心数目
 threadPoolTaskExecutor.setCorePoolSize(5);
 threadPoolTaskExecutor.setAllowCoreThreadTimeOut(true);
 //最大线程数
 threadPoolTaskExecutor.setMaxPoolSize(20);
 //配置队列大小
 threadPoolTaskExecutor.setQueueCapacity(400);
 //配置线程池前缀
 threadPoolTaskExecutor.setThreadNamePrefix("Custom-async-thread-");
 //配置拒绝策略
 threadPoolTaskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
 //数据初始化
 threadPoolTaskExecutor.initialize();
 //是否等待所有线程执行完毕才关闭线程池，默认值为false。
 threadPoolTaskExecutor.setWaitForTasksToCompleteOnShutdown(true);
 //awaitTerminationSeconds：waitForTasksToCompleteOnShutdown的等待的时长，默认值为0，即不等待。
 threadPoolTaskExecutor.setAwaitTerminationSeconds(60);
 // 注入装饰器
 threadPoolTaskExecutor.setTaskDecorator(new MdcTaskDecorator());
 threadPoolTaskExecutor.initialize();
 return threadPoolTaskExecutor;
 }
}
```

```java
public class MdcTaskDecorator implements TaskDecorator {
 /**
 * Decorate the given {@code Runnable}, returning a potentially wrapped
 * {@code Runnable} for actual execution, internally delegating to the
 * original {@link Runnable#run()} implementation.
 *
 * @param runnable the original {@code Runnable}
 * @return the decorated {@code Runnable}
 */
 @Override
 public Runnable decorate(Runnable runnable) {
 return new MdcRunnable(runnable);
 }
}
```

测试示例：

```java
@Slf4j
@Service
public class MyService {
 @Async
 public void asyncMethod() {
 log.info("异步方法执行，traceId: {}", MdcTraceContext.getTraceId());
 }
}
```

全链路日志TraceId穿透异步线程与MQ消息

JUC 基础知识汇总，了解并发编程的全貌



# JUC 基础知识总结

## 线程

### 线程状态
NEW：
> Thread对象被创建出来了，但是还没有执行start方法。

```java
public static void main(String[] args) throws InterruptedException {
 Thread t1 = new Thread(() -> {
 
 });
 System.out.println(t1.getState());
}
```

RUNNABLE：
> Thread对象调用了start方法，就为RUNNABLE状态（CPU调度/没有调度）

```java
public static void main(String[] args) throws InterruptedException {
 Thread t1 = new Thread(() -> {
 while(true){

 }
 });
 t1.start();
 Thread.sleep(500);
 System.out.println(t1.getState());
}
```

BLOCKED：
> synchronized没有拿到同步锁，被阻塞的情况

```java
public static void main(String[] args) throws InterruptedException {
 Object obj = new Object();
 Thread t1 = new Thread(() -> {
 // t1线程拿不到锁资源，导致变为BLOCKED状态
 synchronized (obj){

 }
 });
 // main线程拿到obj的锁资源
 synchronized (obj) {
 t1.start();
 Thread.sleep(500);
 System.out.println(t1.getState());
 }
}
```

WAITING：
> 调用wait方法就会处于WAITING状态，需要被手动唤醒

```java
public static void main(String[] args) throws InterruptedException {
 Object obj = new Object();
 Thread t1 = new Thread(() -> {
 synchronized (obj){
 try {
 obj.wait();
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 }
 });
 t1.start();
 Thread.sleep(500);
 System.out.println(t1.getState());
}
```

TIME_WAITING：
> 调用sleep方法或者join方法，会被自动唤醒，无需手动唤醒

```java
public static void main(String[] args) throws InterruptedException {
 Thread t1 = new Thread(() -> {
 try {
 Thread.sleep(1000);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 });
 t1.start();
 Thread.sleep(500);
 System.out.println(t1.getState());
}
```

BLOCKED、WAITING、TIME_WAITING：都可以理解为是阻塞、等待状态，因为处在这三种状态下，CPU不会调度当前线程

TERMINATED：
> run方法执行完毕，线程生命周期到头了

```java
public static void main(String[] args) throws InterruptedException {
 Thread t1 = new Thread(() -> {
 try {
 Thread.sleep(500);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 });
 t1.start();
 Thread.sleep(1000);
 System.out.println(t1.getState());
}
```

### 线程方法

获取当前线程
```java
Thread thread = Thread.currentThread();
```

获取栈帧
```java
StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();

Map<Thread, StackTraceElement[]> allStackTraces = Thread.getAllStackTraces();
```

获取线程名称
```java
Thread.currentThread().getName();
```

设置线程调度优先级
> java中给线程设置的优先级别有10个级别，从1~10任取一个整数。
```java
Thread.currentThread().setPriority(1);
```

线程的让步
> 可以通过Thread的静态方法yield，让当前线程从运行状态转变为就绪状态。
```java
Thread.yield();
```

线程的等待和唤醒
> 可以让获取synchronized锁资源的线程通过wait方法进去到锁的等待池，并且会释放锁资源
> 
> 可以让获取synchronized锁资源的线程，通过notify或者notifyAll方法，将等待池中的线程唤醒，添加到锁池中
> 
> notify随机的唤醒等待池中的一个线程到锁池
> 
> notifyAll将等待池中的全部线程都唤醒，并且添加到锁池

在调用wait方法和notify以及norifyAll方法时，必须在synchronized修饰的代码块或者方法内部才可以，因为要操作基于某个对象的锁的信息维护。

```java
synchronized (MiTest.class) { 
 MiTest.class.wait();
 MiTest.class.notifyAll(); 
}
```

线程的结束方式
> interrupt方式

```java
public static void main(String[] args) throws InterruptedException {
 // 线程默认情况下， interrupt标记位：false
 System.out.println(Thread.currentThread().isInterrupted());
 // 执行interrupt之后，再次查看打断信息
 Thread.currentThread().interrupt();
 // interrupt标记位：ture
 System.out.println(Thread.currentThread().isInterrupted());
 // 返回当前线程，并归位为false interrupt标记位：ture
 System.out.println(Thread.interrupted());
 // 已经归位了
 System.out.println(Thread.interrupted());

 // =====================================================
 Thread t1 = new Thread(() -> {
 while(!Thread.currentThread().isInterrupted()){
 // 处理业务
 }
 System.out.println("t1结束");
 });
 t1.start();
 Thread.sleep(500);
 t1.interrupt();
}

```


## JMM
JMM (Java Memory Model) 即为Java内存模型

Java内存模型规定了所有的变量都存储在主内存中，每条线程都有自己的工作内存，线程的工作内存中保存了被该线程使用的变量的主内存副本，线程对该变量的所有读写操作都必须在工作内存中进行而不能直接读写主内存中的数据，不同的线程之间也无法访问对方工作内存中的变量，线程间变量值的传递都需要通过主内存来完成

### 特性：
原子性、可见性、有序性

### 内存间的交互

 1. lock：锁定
 > 作用于主内存的变量，它把一个变量标识为一条线程独占的状态

 2. unlock：解锁
 > 作用域主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

 3. read：读取
 > 作用域主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用

 4. load：载入
 > 作用于工作内存的变量，它把read操作从主内存中得到的变量值放入到工作内存的变量副本中

 5. usr：使用
 > 作用于工作内存的变量，它把工作内存中的一个变量的值传给存储引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时会执行这个操作

 6. assign：赋值
 > 作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令执行这个操作

 7. store：存储
 > 作用于工作内存的变量，它把工作内存中的一个变量的值传送到主内存中，以便write操作使用

 8. write：写入
 > 作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中 



## volatile
是Java提供的一种轻量级的同步机制，用来确保将变量的更新操作通知到其他线程

### 特性：
可见性
> 通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值的方式实现可见性的

有序性
> 禁止指令重排序优化
> 通过内存屏障指令保证处理器不会乱序

### 问题：
### volatile 是怎么保证可见性的？

volatile 是通过 **MESI 缓存一致性协议** 来保证可见性的

首先 cpu 会根据共享变量是否带有 volatile 字段，来决定是否使用MESI协议保证缓存一致性。
如果有volatile，汇编层面会对变量加上Lock前缀，当一个线程修改变量的值后，会马上经过store、write等原子操作修改主内存的值（如果不加Lock前缀不会马上同步），为什么监听到修改会马上同步呢？就是为了触发cpu的嗅探机制，及时失效其他线程变量副本。

##### MESI 缓存一致性协议
> 
* M 修改 (Modified) 当一个线程要修改便令
* E 独享、互斥 (Exclusive) 当一个线程拿到了共享变量，此时为独享状态！
* S 共享 (Shared) 当多个线程都拿到了共享变量，此时为共享状态！
* I 无效 (Invalid) 线程丢弃了自己工作内存中的变量，为无效状态！

##### cpu总线嗅探机制
cpu总线嗅探机制监听到这个变量被修改，就会把其他线程的变量副本由共享S置为无效I，当其他线程在使用变量副本时，发现其已经无效，就回去主内存中拿一个最新的值。

##### Lock前缀的作用
使CPU缓存数据立即写会主内存（Volatile修饰的变量会带lock前缀）
触发总线嗅探机制和缓存一致性协议MESI来失效其他线程的变量

### volatile 是怎么保证有序性的？

> 被 volatile 修饰的变量存在一个 lock 前缀的指令，lock 前缀指令实际上相当于一个内存屏障
>
* 确保指令重排序时不会将其后面的代码排到内存屏障之前
* 确保指令重排序时不会将其前面的代码排到内存屏障之后
* 确保在执行到内存屏障修饰的指令时前面的代码全部执行完成
* 强制将线程工作内存中的值的修改刷新至主内存中
* 如果是写操作，则会导致其他线程工作内存中的缓存数据失效


## 本地线程 ThreadLocal

ThreadLocal意为线程本地变量，用于解决多线程并发时访问共享变量的问题。

在多线程的场景下，当有多个线程对共享变量进行修改的时候，就会出现线程安全问题，即数据不一致问题。常用的解决方法是对访问共享变量的代码加锁（synchronized或者Lock）。但是这种方式对性能的耗费比较大。

在JDK1.2中引入了ThreadLocal类，来修饰共享变量，使每个线程都单独拥有一份共享变量，这样就可以做到线程之间对于共享变量的隔离问题。

### 实现原理
- ThreadLocal 有一个内部类 ThreadLocalMap 
- ThreadLocalMap 是一个自定义的哈希映射，仅适用于维护线程本地值。
- ThreadLocalMap 的内部类 Entry 继承了弱引用 WeakReference
- 每个 Thread 中都存储着一个成员变量 ThreadLocal.ThreadLocalMap
- ThreadLocalMap 本身就是基于 Entry[] 实现的，因为一个线程可以绑定多个ThreadLocal，其中 ThreadLocal 作为key，存储的值为value。
- ThreadLocalMap 的key是一个弱引用，弱引用的特点是，即便有弱引用，在GC时，也必须被回收。这里是为了在ThreadLocal对象失去引用后，如果key的引用是强引用，会导致ThreadLocal对象无法被回收
```java
public class ThreadLocal<T> {
 ...
 
 static class ThreadLocalMap {
 static class Entry extends WeakReference<ThreadLocal<?>> {
 /** The value associated with this ThreadLocal. */
 Object value;

 Entry(ThreadLocal<?> k, Object v) {
 super(k);
 value = v;
 }
 }
 
 /**
 * The initial capacity -- MUST be a power of two.
 */
 private static final int INITIAL_CAPACITY = 16;

 /**
 * The table, resized as necessary.
 * table.length MUST always be a power of two.
 */
 private Entry[] table;
}
```

### ThreadLocal内存泄漏问题
在使用的过程中，如果key的引用丢失，也就是 ThreadLocal 的引用丢失后，key会因为弱引用被GC回收，在当前线程内部的 ThreadLocalMap 中，就没有key在指向的value，value无法被获取，更无法被回收，导致value的值一直占用内存，造成内存泄漏。

:::warning{title="解决"}
只需要在使用完毕ThreadLocal对象之后，及时的调用remove方法，移除Entry即可
:::

# 原子变量类

### 什么是CAS
CAS （Compare-and-Swap）就是比较并交换（本质是 `乐观锁` ）

CAS指令需要三个操作数，分别是变量的内存地址，用V表示，旧值用A表示，新值用B表示。CAS指令在执行时，当且当V符合A时，处理器才会用B更新V的值，否则就不更新。不管是否更新了V值，都会返回V的旧值，这个处理过程是一个原子操作，执行期间不会被其他线程中断

### 什么是ABA问题
如果变量V初次读取的变量值是A值，在这段期间它的值曾经被改为B值，后来又被改为A值，那么CAS操作会误认为它从来没有被改变过，这个问题被称为 `ABA` 问题

### 怎么解决ABA问题
解决办法是在每一个线程对变量进行赋值操作时加上版本号信息。
原子类中提供了 AtomicStampedReference 类
通过控制变量值的版本来保证CAS的正确性，可解决CAS的 `ABA` 问题

### 自旋时间过长问题
可以指定CAS自旋次数，如果超过次数，直接挂失败/挂起线程。（自旋锁、自适应自旋锁）
可以在CAS失败之后，把这个操作暂存起来，后面等待获取结果，将暂存的操作全部执行，再返回最后的结果


### 原子类
原子类基于CAS算法实现线程安全，无需加锁，性能高效。

原子操作类可分为五种类型：
基本数据类型原子类、数组类型原子类、引用类型原子类、对象的属性修改类型、高性能原子类

#### 基本数据类型原子类
> AtomicInteger、AtomicLong、AtomicBoolean

#### 数组类型原子类
> AtomicIntegerArray、AtomicLongArray、AtomicReferenceArray

#### 引用类型原子类
> AtomicReference、、AtomicReferenceArray、AtomicStampedReference

#### 基本数据类型原子类
> AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、AtomicReferenceFieldUpdate

注意：对象的属性修改类型都是抽象类，所以在使用之前必须使用静态方法newUpdater创建一个新的更新器，然后参数传入需要更新的类和属性，属性名。同时待修改的属性必须用public volatile关键字修饰。

#### 高性能原子类
> DoubleAccumulator、DoubleAdder、LongAccumulator、LongAdder、Striped64

以LongAdder为例，引入的目的是解决高并发环境下AtomicLong的自旋瓶颈问题。
思想概述：采用分段的思想，将value值分散到一个数组中，不同线程会命中到数组的不同槽中，各个线程只对自己槽中的那个值进行CAS操作，最后再把这些段的值相加得到最终的值


# AbstractQueuedSynchronizer

## 队列同步器的原理分析

### 概述
队列同步器AbstractQueuedSynchronizer（以下简称同步器），是用来构建锁或者其他同步组件的基础框架，它使用了一个volatile int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作，它是大部分同步需求的基础。

同步器的设计是基于模板方法模式的，也就是说，使用者需要继承同步器并重写指定的 方法，随后将同步器组合在自定义同步组件的实现中，并调用同步器提供的模板方法，而这些 模板方法将会调用使用者重写的方法。

重写同步器指定的方法时，需要使用同步器提供的如下3个方法来访问或修改同步状态。 
>* getState()：获取当前同步状态。
>* setState(int newState)：设置当前同步状态。 
>* compareAndSetState(int expect,int update)：使用CAS设置当前状态，该方法能够保证状态 设置的原子性。

![同步状态方法](https://img-blog.csdnimg.cn/f05d1f8fd4844a02832094703b853cea.png)

同步状态可以表示任意状态，例如：

 ReentrantLock 中用它来标识所有者线程已经重复获取该锁的次数
 Semaphore 用它来表示剩余的许可数量
 FutureTask 用它来表示任务的状态（尚未开始、正在运行、已完成以及已注销）

在同步器类中还可以自行管理一些额外的状态变量：

 ReentrantLock 保存了锁当前所有者的信息，能区分某个获取操作是重入的还是竞争的
 

同步器可重写的方法：
|方法名称 | 描述|
|--|--|
|protected boolean tryAcquire(int arg) | 独占式获取同步状态，实现该方法需要查询当前状态并判断同步状态是否符合预期，然后再进行CAS设置同步状态 |
|protected boolean tryRelease(int arg) | 独占式释放同步状态，等待获取同步状态的线程将有机会获取同步状态 |
|protected int tryAcquireShared(int arg) | 共享式获取同步状态，返回大于等于0的值，表示获取成功，反之，获取失败 |
|protected boolean tryReleaseShared(int arg) | 共享式释放同步状态 |
|protected boolean isHeldExclusively() | 当前同步器是否在独占模式下被线程占用，一般该方法标识是否被当前线程所独占 |

同步器提供的模板方法基本上分为3类：独占式获取与释放同步状态、共享式获取与释放同步状态和查询同步队列中的等待线程情况。自定义同步组件将使用同步器提供的模板方法来实现自己的同步语义。

### 个人理解
ReentrantLock、 ReentrantReadWriteLock和CountDownLatch等锁实际上是内部定义的类实现的，同步器是实现锁的关键，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。锁的实现又分为互斥锁与共享锁,分别对应同步器的独占式与共享式操作同步状态。

![AQS的实现](https://img-blog.csdnimg.cn/954a5039aaaa44139aa3b26f82e7a964.png)

## 队列同步器的实现分析

### 同步队列

同步器依赖内部的同步队列（一个FIFO双向队列）来完成同步状态的管理，当前线程获取 同步状态失败时，同步器会将当前线程以及等待状态等信息构造成为一个节点（Node）并将其 加入同步队列，同时会阻塞当前线程，当同步状态释放时，会把首节点中的线程唤醒，使其再 次尝试获取同步状态。

同步队列中的节点（Node）用来保存获取同步状态失败的线程引用、等待状态以及前驱和后继节点，节点的属性类型与名称以及描述。
![双向队列](https://img-blog.csdnimg.cn/6ab32d9bd02b454588391c8bef7c1d7a.png)




# ReentrantLock

### ReentrantLock 的实现原理
ReentrantLock底层是基于AQS实现的，通过AQS维护的 volatile 的 state 变量来实现锁操作的。
ReentrantLock实现了Lock接口，并提供了与synchronized相同的互斥性和内存可见性。
与synchronized一样，ReentrantLock也提供了可重入的加锁语义。

JUC 基础知识总结

衡量一个服务性能的高低好坏，每秒事务处理数（Transactions Per Second， TPS）是重要的指标之一，它代表着一秒内服务端平均能响应的请求总数，而TPS值与程序的并发能力又有非常密切的关系。对于计算量相同的任务，程序线程并发协调得越有条不紊，效率自然就会越高；反之，线程之间频繁争用数据，互相阻塞甚至死锁，将会大大降低程序的并发能力。



# JVM内存模型与锁优化

## Java内存模型

### 概述
Java内存模型规定了所有的变量都存储在主内存（Main Memory）中。每条线程都有自己的工作内存（Working Memory），线程的工作内存中保存了被该线程使用的变量的主内存副本，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。线程与线程之间的变量数据是不可见的。

### 内存间交互操作
关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存这一类的实现细节，Java内存模型中定义了以下8种操作来完成。Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的。

>* lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。 >* >* unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量 才可以被其他线程锁定。 
>* read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以 便随后的load动作使用。 
>* load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的 变量副本中。
>* use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚 拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
>* assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收的值赋给工作内存的变量， 每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
>* store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随 后的write操作使用。
>* write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的 变量中。

这8种内存访问操作以及上述规则限定，再加上稍后会介绍的专门针对volatile的一些特殊规定，就已经能准确地描述出Java程序中哪些内存访问操作在并发下才是安全的。

这种定义相当严谨，但也是极为烦琐，实践起来更是无比麻烦。可能部分读者阅读到这里已经对多线程开发产生恐惧感了，后来Java设计团队大概也意识到了这个问题，将Java内存模型的操作简化为read、write、lock和unlock四种。

### volatile
**关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制**

**当一个变量被定义成volatile之后，它将具备两项特性：** 

第一项是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。而普通变量并不能做到这一点，普通变量的值在线程间传递时均需要通过主内存来完成。比如，线程A修改一个普通变量的值，然后向主内存进行回写，另外一条线程B在线程A回写完成了之后再对主内存进行读取操作，新变量值才会对线程B可见。
 
 **可见性的原理：被volatile修饰的变量在工作内存中使用前都会先刷新。**
 
由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁 （使用synchronized、java.util.concurrent中的锁或原子类）来保证原子性：

>* 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
>* 变量不需要与其他的状态变量共同参与不变约束。

使用volatile变量的第二个语义是禁止指令重排序优化，普通的变量仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。

有volatile修饰的变量，赋值后多执行了一个“lock addl$0x0，(%esp)”操作，这个操作的作用相当于一个内存屏障 （Memory Barrier或Memory Fence，指重排序时不能把后面的指令重排序到内存屏障之前的位置）。

解决了volatile的语义问题，再来看看在众多保障并发安全的工具中选用volatile的意义——**它能让我们的代码比使用其他的同步工具更快吗？**

 在某些情况下，volatile的同步机制的性能确实要优于锁（使用synchronized关键字或java.util.concurrent包里面的锁），但是由于虚拟机对锁实行的许多消除和优化，使得我们很难确切地说volatile就会比synchronized快上多少。
 
 如果让volatile自己与自己比较，那可以确定一个原则：volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢上一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过即便如此，大多数场景下volatile的总开销仍然要比锁来得更低。
 
总结：我们在volatile与锁中选择的唯一判断依据仅仅是volatile的语义能否满足使用场景的需求。

### 内存模型的特性

#### 原子性（Atomicity）

如果应用场景需要一个更大范围的原子性保证（经常会遇到），Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作。这两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

#### 可见性（Visibility）

Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此。

普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此我们可以说volatile保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。

除了volatile之外，Java还有两个关键字能实现可见性，它们是synchronized和final。

#### 有序性（Ordering）

Java内存模型的有序性在前面讲解volatile时也比较详细地讨论过了，Java程序中天然的有序性可以总结为一句话：

 如果在本线程内观察，所有的操作都是有序的；
 如果在一个线程中观察另一个线程，所有的操作都是无序的。

前半句是指“线程内似表现为串行的语义”（Within-Thread As-If-Serial Semantics），后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。

Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻只允许一条线程对 其进行lock操作”这条规则获得的，这个规则决定了持有同一个锁的两个同步块只能串行地进入。


## 线程状态
Java语言定义了6种线程状态，在任意一个时间点中，一个线程只能有且只有其中的一种状态，并且可以通过特定的方法在不同状态之间转换。这6种状态分别是：

### 新建（New）：
创建后尚未启动的线程处于这种状态。

### 运行（Runnable）：
包括操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可 能正在执行，也有可能正在等待着操作系统为它分配执行时间。

### 无限期等待（Waiting）：
处于这种状态的线程不会被分配处理器执行时间，它们要等待被其他线 程显式唤醒。以下方法会让线程陷入无限期的等待状态：
>* 没有设置Timeout参数的Object::wait()方法；
>* 没有设置Timeout参数的Thread::join()方法；
>* LockSupport::park()方法。 

### 限期等待（Timed Waiting）：
处于这种状态的线程也不会被分配处理器执行时间，不过无须等待被其他线程显式唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程进入限期等待状态：
>* Thread::sleep()方法； 
>* 设置了Timeout参数的Object::wait()方法； 
>* 设置了Timeout参数的Thread::join()方法； 
>* LockSupport::parkNanos()方法； 
>* LockSupport::parkUntil()方法。 

### 阻塞（Blocked）：
线程被阻塞了，“阻塞状态”与“等待状态”的区别是“阻塞状态”在等待着获取到一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状态”则是在等待一段时 间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态。 

### 结束（Terminated）：
已终止线程的线程状态，线程已经结束执行


## 线程安全

### 线程安全的实现

#### 互斥同步

在Java里面，最基本的互斥同步手段就是synchronized关键字，这是一种块结构（Block Structured）的同步语法。synchronized关键字经过Javac编译之后，会在同步块的前后分别形成 `monitorenter` 和 `monitorexit` 这两个字节码指令。

根据《Java虚拟机规范》的要求，**在执行 `monitorenter` 指令时，首先要去尝试获取对象的锁。如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行 `monitorexit` 指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。（可重入锁的原理，此处以 synchronized 举例）**

自JDK 5起 （实现了JSR 166[1]），Java类库中新提供了java.util.concurrent包（下文称J.U.C包），其中的 java.util.concurrent.locks.Lock接口便成了Java的另一种全新的互斥同步手段。基于Lock接口，用户能够 以非块结构（Non-Block Structured）来实现互斥同步，从而摆脱了语言特性的束缚，改为在类库层面 去实现同步，这也为日后扩展出不同调度算法、不同特征、不同性能、不同语义的各种锁提供了广阔的空间。

重入锁（ReentrantLock）是Lock接口最常见的一种实现，顾名思义，它与synchronized一样是可重入的。在基本用法上，ReentrantLock也与synchronized很相似，只是代码写法上稍有区别而已。

**Synchronized 与 ReentrantLock 锁的区别，主要有以下三项：**
**等待可中断、可实现公平锁、锁可以绑定多个条件**

**等待可中断：**
是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。可中断特性对处理执行时间非常长的同步块很有帮助。

**公平锁、非公平锁：**
是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平 锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非 公平的，ReentrantLock在默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁。不过一旦使用了公平锁，将会导致ReentrantLock的性能急剧下降，会明显影响吞吐量。 

**锁绑定多个条件：**
是指一个ReentrantLock对象可以同时绑定多个Condition对象。
在synchronized 中，锁对象的wait()跟它的notify()或者notifyAll()方法配合可以实现一个隐含的条件，如果要和多于一个的条件关联的时候，就不得不额外添加一个锁；
而ReentrantLock则无须这样做，多次调用newCondition()方法即可。

#### 非阻塞同步

**互斥同步面临的主要问题是进行线程阻塞和唤醒所带来的性能开销，因此这种同步也被称为阻塞同步（Blocking Synchronization）。**

从解决问题的方式上看，互斥同步属于一种悲观的并发策略，其总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享的数据是否真的会出现竞争，它都会进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加 锁），这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开销。

随着硬件指令集的发展，我们已经有了另外一个选择：**基于冲突检测的乐观并发策略，通俗地说就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现没有竞争的共享数据为止。这种乐观并发策略的实现不再需要把线程阻塞挂起，因此这种同步操作被 称为非阻塞同步（Non-Blocking Synchronization）**，使用这种措施的代码也常被称为无锁（Lock-Free） 编程。

**比较并交换（Compare-and-Swap，下文称CAS）；**

**CAS指令需要有三个操作数，分别是内存位置（在Java中可以简单地理解为变量的内存地址，用V 表示）、旧的预期值（用A表示）和准备设置的新值（用B表示）。
CAS指令执行时，当且仅当V符合A时，处理器才会用B更新V的值，否则它就不执行更新。但是，不管是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断。**

CAS具体实现：AtomicInteger #incrementAndGet()方法的JDK源码
```java
/**
 * Atomically increment by one the current value. 
 * @return the updated value
 */ 
public final int incrementAndGet() { 
 for (;;) { 
 int current = get(); 
 int next = current + 1; 
 if (compareAndSet(current, next)) 
 return next;
 } 
}
```

incrementAndGet()方法在一个无限循环中，不断尝试将一个比当前值大一的新值赋值给自己。如果失败了，那说明在执行CAS操作的时候，旧值已经发生改变，于是再次循环进行下一次操作，直到设置成功为止。

尽管CAS看起来很美好，既简单又高效，但显然这种操作无法涵盖互斥同步的所有使用场景，并且CAS从语义上来说并不是真正完美的，它存在一个逻辑漏洞：如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然为A值，那就能说明它的值没有被其他线程改变过了吗？

**“ABA”问题**

这是不能的，因为如果在这段期间它的值曾经被改成B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的“ABA问题”。J.U.C包为了解决这个问题，提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。不过目前来说这个类处于相当鸡肋的位置，大部分情况下ABA问题不会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更为高效。
 

## 锁优化

### 自旋锁与自适应锁

### 锁消除

### 锁粗化

### 轻量级锁

### 偏向锁

JVM 高效并发核心知识

# Mysql性能调优总结篇

## 优化方向
**如何创建索引：** 
索引列的顺序的选择（将选择性更高的列放到索引最前列）、创建覆盖索引、索引下推
 
**查询索引优化：** 
最左前缀原则，小表驱动大表，避免join连接多个表，延迟关联（mybatis的延迟关联查询），避免多个范围查询，索引信息统计、减少表数据与索引的碎片、索引失效的场景（使用函数、关联查询的字段字符集与数据类型不一致...）

**库表优化：** 
选择适合的类型，类型越简单越好，避免NULL

## B+Tree数据结构
主要分为非叶子页节点与叶子页节点
InnoDB 将数据划分为若干个页，InnoDB 中页的大小默认为 16KB
所有的值都是按顺序存储的，并且每一个叶子页到根的距离相同
叶子节点使用双向指针相互连接，形成一个双向链表方便范围查找

**总结：**
由于B+树非叶子节点只存储了索引，这样大大提高了每个非叶子节点可以存储的数据行数量，保证了树的高度可控。
同时叶子节点使用双向指针连接形成链表，在执行范围查询，排序等操作时避免了重复从根节点开始查找数据。
所以InnoDB最终选择了B+树作为索引的数据结构。

### 聚簇索引
聚簇索引并不是一种单独的索引类型，而是一种**数据存储方式**。

**一个表只能有一个聚簇索引**，InnoDB 将通过主键聚集数据，如果没有定义主键，InnoDB会选择一个唯一的非空索引代替，如果没有这样的索引，InnoDB 会隐式定义一个主键作为聚簇索引。

聚簇索引的每个叶子节点都包含了主键值、事务ID、用于事务和 MVCC 的回滚指针以及剩余列

如果创建索引的字段不是主键字段，那么在叶子节点中存储的是该记录的主键，然后通过主键去查找对应的行数据，叫做回表查询

最好避免随机的（不连续且值的分布范围非常大）聚簇索引，特别是对于 I/O 密集型的应用，例如：从性能的角度考虑，使用 UUID 来作为聚簇索引会很糟糕，它使得聚簇索引的插入变得完全随机。UUID 主键插入行不仅花费的时间更长，而且索引占用的空间也更大

### 二级索引（非聚簇索引）

二级索引的叶子节点包含了引用行的主键列，二级索引访问需要两次索引查找，而不是一次
二级索引叶子节点保存的不是指向行的物理位置的指针，而是行的主键值，并以此作为指向行的“指针”


## 名词

### 覆盖索引
如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们称之为 **覆盖索引**
如果索引的叶子节点中已经包含要查询的数据，那么没什么必要再回表查询了
覆盖索引必须要存储索引列的值，MySQL 只能使用 B-Tree 索引做覆盖索引
InnoDB 的二级索引在叶子节点中保存了行的主键值，所以如果二级主键能够覆盖查询，则可以避免对主键索引的二次查询
当发起一个被索引覆盖的查询，**在 Explain 的 `Extra` 列可以看到 `Usung index` 的信息**

### 索引下推
索引下推( Index Condition Pushdown ，简称ICP)，是MySQL5.6版本的新特性，它能**减少回表查询次数**，提高查询效率

不使用索引条件下推优化时：
> - 存储引擎读取索引记录
> - 根据索引中的主键值，定位并读取完整的行记录
> - 返回给MySQL服务层，服务层判断数据是否符合条件

当使用索引条件下推优化时：
> - 存储引擎读取索引记录（不是完整的行记录）
> - 存在某些被索引的列的判断条件时，MySQL服务层将这一部分判断条件传递给存储引擎
> - 判断条件部分能否用索引中的列来做检查，条件不满足，则处理下一行索引记录；
> - 条件满足，使用索引中的主键去定位并读取完整的行记录（就是所谓的回表）；
> - 存储引擎把记录交给服务层，服务层检测该记录是否满足条件的其余部分

Mysql性能调优总结篇

baidu-site-verification

本人自己的博客，对工作与学习过程中的总结、一些场景设计的实现方案、遇到过的疑难问题与解决、以及面试总结等。