volatile 关键字深度拆解：从内存屏障底层到单例模式的工业级架构设计

引言

在Java并发编程中，volatile是最基础也最容易被误解的关键字。很多开发者只知道它能解决多线程的可见性问题，却对它的禁止指令重排序语义一知半解，甚至在双重检查锁单例中盲目使用，最终埋下线上空指针、数据错乱的隐患。本文将从Java内存模型的底层原理出发，一步步拆解volatile的核心语义，用通俗的语言讲透内存屏障的实现机制，再结合单例模式的架构演进，手把手教你写出工业级的线程安全单例，同时梳理常见误区与最佳实践，让你彻底吃透volatile关键字。

一、并发编程的三大核心问题与Java内存模型

1.1 可见性：CPU缓存与线程工作内存的博弈

在现代计算机架构中，CPU为了提升执行效率，并不会直接与主内存交互，而是通过多层高速缓存完成数据读写。多核心场景下，不同CPU核心的缓存之间会出现数据不一致的问题，这就是硬件层面的可见性问题。

Java内存模型（JMM）是Java语言规范定义的一套内存访问规则，用于屏蔽不同硬件和操作系统的内存访问差异，解决多线程场景下的内存一致性问题。JMM规定：

• 所有共享变量都存储在主内存中
• 每个线程拥有独立的工作内存，保存了该线程使用到的共享变量的主内存副本
• 线程对变量的所有读写操作都必须在工作内存中完成，不能直接操作主内存
• 不同线程之间无法直接访问对方的工作内存，变量值的传递必须通过主内存完成

这种模型带来了天然的可见性问题：当线程A修改了工作内存中的变量副本，若未及时刷新到主内存，其他线程无法感知到变量的变化。下面的示例可以直观复现这个问题：

package com.jam.demo;

import lombok.extern.slf4j.Slf4j;
import org.springframework.util.StopWatch;

@Slf4j
public class VolatileVisibilityDemo {
   private static boolean flag = false;

   public static void main(String[] args) throws InterruptedException {
       StopWatch stopWatch = new StopWatch();
       stopWatch.start();

       Thread readerThread = new Thread(() -> {
           log.info("读线程启动，等待flag变为true");
           while (!flag) {
           }
           log.info("读线程检测到flag变为true，执行结束");
       }, "reader-thread");

       Thread writerThread = new Thread(() -> {
           log.info("写线程启动，3秒后修改flag");
           try {
               Thread.sleep(3000);
           } catch (InterruptedException e) {
               Thread.currentThread().interrupt();
               log.error("写线程被中断", e);
           }
           flag = true;
           log.info("写线程已将flag修改为true");
       }, "writer-thread");

       readerThread.start();
       writerThread.start();

       readerThread.join();
       stopWatch.stop();
       log.info("程序执行总耗时：{}ms", stopWatch.getTotalTimeMillis());
   }
}


上述代码中，未给flag添加volatile修饰时，读线程会永久陷入死循环。原因是JIT编译器会对代码做优化，将flag变量的值缓存在寄存器中，不会重新从主内存读取最新值，导致写线程的修改对读线程完全不可见。

1.2 原子性：复合操作的线程安全陷阱

原子性指的是一个操作是不可分割的，要么全部执行完成，要么完全不执行，执行过程中不会被其他线程中断。

Java中，对基础类型变量的单次读/写操作是原子性的，但复合操作不具备原子性，例如常见的count++自增操作，在字节码层面会被拆分为三个步骤：

1. 从主内存读取count的当前值到工作内存
2. 在执行引擎中对count值加1
3. 将计算后的新值写回工作内存，并刷新到主内存

多线程场景下，多个线程同时执行自增操作时，会出现指令交错，导致最终结果不符合预期。下面的示例可以验证这一点：

package com.jam.demo;

import lombok.extern.slf4j.Slf4j;
import java.util.concurrent.CountDownLatch;

@Slf4j
public class VolatileAtomicityDemo {
   private static volatile int count = 0;
   private static final int THREAD_COUNT = 10;
   private static final int INCREMENT_COUNT = 1000;
   private static final CountDownLatch countDownLatch = new CountDownLatch(THREAD_COUNT);

   public static void main(String[] args) throws InterruptedException {
       for (int i = 0; i < THREAD_COUNT; i++) {
           new Thread(() -> {
               for (int j = 0; j < INCREMENT_COUNT; j++) {
                   count++;
               }
               countDownLatch.countDown();
           }, "increment-thread-" + i).start();
       }

       countDownLatch.await();
       log.info("预期结果：{}，实际结果：{}", THREAD_COUNT * INCREMENT_COUNT, count);
   }
}


上述代码中，即使给count添加了volatile修饰，最终的执行结果依然大概率小于预期的10000。这直接证明了volatile无法保证复合操作的原子性，这是开发者最容易踩的误区之一。

1.3 有序性：指令重排序与as-if-serial语义

为了提升程序执行性能，编译器和CPU会对指令序列进行重排序，分为三类：

1. 编译器优化重排序：编译器在不改变单线程程序语义的前提下，重新安排语句的执行顺序
2. 指令级并行重排序：CPU将多条指令重叠执行，在不改变单线程执行结果的前提下调整指令执行顺序
3. 内存系统重排序：CPU缓存和主内存的读写缓冲，导致加载和存储操作看上去可能是乱序执行

JMM通过as-if-serial语义约束重排序行为：不管怎么重排序，单线程程序的执行结果不能被改变。编译器、CPU都必须遵守as-if-serial语义，也就是说，对存在数据依赖的操作，不会进行重排序。

但as-if-serial语义仅对单线程有效，多线程场景下，指令重排序会导致线程安全问题。下面的示例可以复现重排序带来的异常：

package com.jam.demo;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class ReorderDemo {
   private static int a = 0;
   private static int b = 0;
   private static boolean flag = false;

   public static void main(String[] args) throws InterruptedException {
       int errorCount = 0;
       for (int i = 0; i < 10000; i++) {
           // 重置变量
           a = 0;
           b = 0;
           flag = false;

           Thread thread1 = new Thread(() -> {
               a = 1;
               flag = true;
           });

           Thread thread2 = new Thread(() -> {
               if (flag) {
                   b = a;
               }
           });

           thread1.start();
           thread2.start();
           thread1.join();
           thread2.join();

           if (b == 0 && flag) {
               errorCount++;
               log.error("第{}次执行出现重排序，b=0，flag=true", i);
           }
       }
       log.info("10000次执行中，重排序出现次数：{}", errorCount);
   }
}


上述代码中，单线程视角下，a=1和flag=true的执行顺序不会影响结果，编译器和CPU可能会将两者重排序。当flag=true先于a=1执行时，thread2会先读取到flag为true，此时a还未被赋值，最终b=0，出现不符合预期的结果。

1.4 happens-before规则：并发编程的可见性保证

JMM通过happens-before规则向开发者提供跨线程的可见性保证，无需了解底层重排序规则，只需遵守happens-before规则，就能保证多线程场景下的可见性。

核心happens-before规则如下：

1. 程序顺序规则：一个线程内，按照代码执行顺序，前面的操作happens-before于后面的任意操作
2. 监视器锁规则：对一个锁的解锁操作，happens-before于后续对这个锁的加锁操作
3. volatile变量规则：对一个volatile变量的写操作，happens-before于后续任意对这个volatile变量的读操作
4. 线程启动规则：Thread对象的start()方法调用，happens-before于该线程内的任意操作
5. 线程终止规则：线程内的所有操作，都happens-before于其他线程检测到该线程终止
6. 传递性规则：如果A happens-before B，且B happens-before C，那么A happens-before C

其中，volatile变量规则是理解volatile语义的核心，结合传递性规则，volatile不仅能保证自身变量的可见性，还能实现更强大的跨线程内存可见性保证。

二、volatile关键字的核心语义与底层实现

2.1 语义一：保证多线程间的变量可见性

volatile的第一个核心语义是保证共享变量的多线程可见性：

• 当一个线程修改了volatile变量的值，会立即将最新值强制刷新到主内存
• 当其他线程读取volatile变量时，会强制将工作内存中的变量副本置为无效，重新从主内存读取最新值

回到1.1中的可见性示例，给flag变量添加volatile修饰后，写线程修改flag后会立即刷新到主内存，读线程每次循环都会从主内存读取最新的flag值，3秒后会正常退出循环，不会出现死循环问题。

同时，Java语言规范明确规定：volatile修饰的long和double类型变量，即使在32位JVM中，也保证单次读/写操作的原子性，解决了32位JVM中long/double变量的非原子性读写问题。

2.2 语义二：禁止指令重排序

volatile的第二个核心语义是禁止指令重排序，通过内存屏障限制编译器和CPU的重排序行为，具体规则如下：

1. 当程序执行到volatile变量的读操作时，读操作之前的所有操作必须已经执行完成，且结果对后续操作可见；读操作之后的操作不能被重排序到读操作之前
2. 当程序执行到volatile变量的写操作时，写操作之前的所有操作必须已经执行完成，且结果对后续操作可见；写操作之后的操作不能被重排序到写操作之前
3. 禁止两个volatile变量之间的读写操作发生重排序

结合happens-before的传递性规则，volatile的禁止重排序语义实现了更强大的内存可见性：线程A在写volatile变量之前的所有普通变量写操作，都会随着volatile变量的写操作一起刷新到主内存；线程B在读volatile变量之后，会将工作内存中的普通变量副本置为无效，重新从主内存读取最新值，也就是说，线程A写volatile之前的所有操作，对线程B读volatile之后的所有操作都是可见的。

2.3 底层实现：内存屏障与MESI缓存一致性协议

JVM通过内存屏障（Memory Barrier）指令实现volatile的可见性和禁止重排序语义。内存屏障是一组CPU指令，用于控制特定操作的执行顺序和内存可见性。

JMM定义了四类内存屏障：

为了实现volatile的完整语义，JVM在编译期会按照如下策略插入内存屏障：

1. 在每个volatile写操作前，插入StoreStore屏障
2. 在每个volatile写操作后，插入StoreLoad屏障
3. 在每个volatile读操作后，插入LoadLoad屏障
4. 在每个volatile读操作后，插入LoadStore屏障

而volatile的可见性，底层依赖于CPU的MESI缓存一致性协议：

• M（Modified）：缓存行被修改，与主内存数据不一致
• E（Exclusive）：缓存行独占，与主内存数据一致
• S（Shared）：缓存行被多个CPU共享，与主内存数据一致
• I（Invalid）：缓存行失效，不可用

当CPU修改了volatile变量所在的缓存行，会将该缓存行标记为Modified状态，并通过总线嗅探机制通知其他CPU，将对应缓存行标记为Invalid状态。其他CPU需要读取该变量时，发现缓存行已失效，会强制从主内存重新加载最新的缓存行，从而保证多线程间的变量可见性。

2.4 JSR-133对volatile内存语义的增强

在JDK1.5之前，volatile虽然能保证可见性，但无法完全禁止指令重排序，导致双重检查锁单例存在线程安全问题。JDK1.5版本通过JSR-133规范修复了这一问题，增强了volatile的内存语义，完善了happens-before规则，明确了volatile变量的写/读可以实现跨线程的内存可见性传递，彻底解决了volatile禁止重排序语义的缺陷。

三、单例模式的架构演进与volatile的核心作用

3.1 单例模式的核心设计原则

单例模式是创建型设计模式中最常用的模式之一，核心设计原则是：保证一个类在任何场景下都只有一个实例，并提供一个全局唯一的访问入口。

一个合格的工业级单例实现，需要满足以下要求：

1. 线程安全：多线程场景下不会创建多个实例
2. 懒加载：只有在第一次使用时才创建实例，避免资源浪费
3. 高性能：获取实例的操作不需要频繁加锁，性能损耗低
4. 安全防护：防止反射、序列化等方式破坏单例

3.2 饿汉式单例：类加载即初始化的实现

饿汉式单例是最简单的单例实现，在类加载的初始化阶段就完成实例的创建，基于JVM的类加载机制保证线程安全。

package com.jam.demo;

public class EagerSingleton {
   private static final EagerSingleton INSTANCE = new EagerSingleton();

   private EagerSingleton() {
       if (INSTANCE != null) {
           throw new IllegalStateException("单例类禁止重复实例化");
       }
   }

   public static EagerSingleton getInstance() {
       return INSTANCE;
   }
}


优点：实现简单，类加载时完成实例初始化，无线程安全问题，获取实例的性能极高。缺点：无法实现懒加载，类加载时就会创建实例，若实例初始化耗时较长，会增加类加载的时间；若实例始终未被使用，会造成内存资源的浪费。

3.3 懒汉式单例：懒加载的演进与线程安全问题

懒汉式单例实现了懒加载，只有在第一次调用获取实例的方法时，才会创建实例。

非线程安全的懒汉式实现

package com.jam.demo;

public class LazyUnsafeSingleton {
   private static LazyUnsafeSingleton instance;

   private LazyUnsafeSingleton() {
   }

   public static LazyUnsafeSingleton getInstance() {
       if (instance == null) {
           instance = new LazyUnsafeSingleton();
       }
       return instance;
   }
}


该实现仅适用于单线程场景，多线程环境下，多个线程同时判断instance为null时，会同时进入实例化逻辑，创建多个实例，破坏单例的核心原则。

同步方法的线程安全懒汉式实现

package com.jam.demo;

public class LazySyncSingleton {
   private static LazySyncSingleton instance;

   private LazySyncSingleton() {
   }

   public static synchronized LazySyncSingleton getInstance() {
       if (instance == null) {
           instance = new LazySyncSingleton();
       }
       return instance;
   }
}


通过给getInstance方法添加synchronized修饰，保证同一时间只有一个线程能进入该方法，解决了多线程安全问题。但该实现的缺陷非常明显：每次获取实例都需要加锁，即使实例已经创建完成，依然会进行锁竞争，带来极大的性能损耗，不适用于高并发场景。

3.4 双重检查锁（DCL）的致命缺陷：指令重排序的坑

为了解决同步方法的性能问题，开发者提出了双重检查锁（Double Check Lock，DCL）的实现，在保证线程安全的同时，大幅提升获取实例的性能。

package com.jam.demo;

public class DclUnsafeSingleton {
   private static DclUnsafeSingleton instance;

   private DclUnsafeSingleton() {
   }

   public static DclUnsafeSingleton getInstance() {
       if (instance == null) {
           synchronized (DclUnsafeSingleton.class) {
               if (instance == null) {
                   instance = new DclUnsafeSingleton();
               }
           }
       }
       return instance;
   }
}


DCL的执行流程如下：

该实现通过两次null值检查，只有在实例未创建时才会加锁，实例创建完成后，后续获取实例的操作无需加锁，直接返回实例，性能大幅提升。

但这个看似完美的实现，存在一个致命的线程安全缺陷，根源就是指令重排序。

instance = new DclUnsafeSingleton()实例化对象的操作，在字节码层面会被拆分为三个步骤：

1. 分配对象所需的内存空间
2. 初始化对象，执行构造方法中的初始化逻辑
3. 将instance引用指向分配的内存地址，此时instance不再为null

编译器和CPU为了提升性能，可能会对步骤2和步骤3进行重排序，执行顺序变为1->3->2。在单线程场景下，as-if-serial语义保证重排序不会影响执行结果，不会出现问题。

但多线程场景下，会出现如下异常执行流程：

1. 线程A调用getInstance方法，判断instance为null，进入同步代码块
2. 线程A执行instance = new DclUnsafeSingleton()，先分配内存空间，然后将instance引用指向分配的内存地址，此时instance已经不为null，但对象还未完成初始化
3. 线程B调用getInstance方法，第一次检查instance不为null，直接返回未完成初始化的instance实例
4. 线程B使用该实例时，会访问到未初始化的成员变量，触发空指针异常，导致程序崩溃

这就是DCL实现中最隐蔽的坑，在高并发场景下，这个问题会被放大，造成线上故障。

3.5 volatile如何修复DCL单例的线程安全问题

要修复DCL单例的缺陷，核心是禁止对象初始化和instance引用赋值之间的指令重排序，而volatile的禁止重排序语义，正好可以解决这个问题。

给instance变量添加volatile修饰后，编译器会插入对应的内存屏障，禁止步骤2和步骤3的重排序，保证对象的初始化操作必须在instance引用赋值之前完成。同时，结合volatile的可见性语义，当instance实例创建完成后，其他线程能立即感知到，不会读取到未初始化的半熟对象。

DCL单例正确实现如下：

package com.jam.demo;

public class DclSingleton {
   private static volatile DclSingleton instance;

   private DclSingleton() {
       if (instance != null) {
           throw new IllegalStateException("单例类禁止重复实例化");
       }
   }

   public static DclSingleton getInstance() {
       if (instance == null) {
           synchronized (DclSingleton.class) {
               if (instance == null) {
                   instance = new DclSingleton();
               }
           }
       }
       return instance;
   }
}


该实现完全满足工业级单例的所有要求：

1. 线程安全：volatile禁止重排序，synchronized保证实例化的原子性，多线程场景下不会创建多个实例
2. 懒加载：只有第一次调用getInstance方法时才会创建实例，不会浪费内存资源
3. 高性能：实例创建完成后，后续获取实例无需加锁，仅需一次volatile读操作，性能损耗极低
4. 安全防护：私有构造方法中添加了实例校验，防止反射破坏单例

3.6 其他工业级单例实现的对比与选型

静态内部类单例

静态内部类单例基于JVM的类加载机制实现，同样能保证线程安全和懒加载。

package com.jam.demo;

public class StaticInnerClassSingleton {
   private StaticInnerClassSingleton() {
       if (SingletonHolder.INSTANCE != null) {
           throw new IllegalStateException("单例类禁止重复实例化");
       }
   }

   public static StaticInnerClassSingleton getInstance() {
       return SingletonHolder.INSTANCE;
   }

   private static class SingletonHolder {
       private static final StaticInnerClassSingleton INSTANCE = new StaticInnerClassSingleton();
   }
}


该实现的核心原理是：静态内部类SingletonHolder只有在第一次调用getInstance方法时才会被加载和初始化，INSTANCE实例的创建在类初始化阶段完成，JVM的类初始化锁保证同一时间只有一个线程能执行类的初始化，不会出现线程安全问题。同时，该实现无需添加volatile修饰，因为JVM会保证类初始化过程中的指令重排序对其他线程不可见。

枚举单例

枚举单例是《Effective Java》中推荐的单例实现，也是目前最安全的单例实现方式。

package com.jam.demo;

public enum EnumSingleton {
   INSTANCE;

   public void doSomething() {
       // 业务逻辑实现
   }
}


枚举单例的优势非常明显：

1. 实现最简单，无需手动处理线程安全和懒加载问题
2. 天然防止反射破坏：JVM禁止通过反射创建枚举实例
3. 天然防止序列化破坏：枚举的序列化和反序列化由JVM保证，反序列化时会返回同一个枚举实例
4. 线程安全：枚举实例的创建在类初始化阶段完成，由JVM保证线程安全

不同单例实现的选型建议：

1. 无需懒加载，实例初始化耗时短：优先选择饿汉式单例，实现最简单，性能最高
2. 需要懒加载，对性能要求高：优先选择DCL单例（必须加volatile）或静态内部类单例
3. 需要防止反射和序列化破坏，追求最高安全性：优先选择枚举单例

四、volatile在生产环境的典型应用场景

4.1 线程状态标记位

volatile最经典的应用场景是线程的启停状态标记位，通过volatile修饰的boolean变量，控制线程的执行状态，实现线程的优雅停止。

package com.jam.demo;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class ThreadStopDemo {
   private static volatile boolean running = true;

   public static void main(String[] args) throws InterruptedException {
       Thread taskThread = new Thread(() -> {
           log.info("任务线程启动");
           while (running) {
               // 执行业务任务
               try {
                   Thread.sleep(100);
               } catch (InterruptedException e) {
                   Thread.currentThread().interrupt();
                   log.error("任务线程被中断", e);
               }
           }
           log.info("任务线程收到停止信号，优雅退出");
       }, "task-thread");

       taskThread.start();
       Thread.sleep(3000);
       running = false;
       log.info("主线程已发送停止信号");
       taskThread.join();
       log.info("程序执行结束");
   }
}


该场景完全符合volatile的使用条件：对running变量的写操作不依赖当前值，只有主线程会修改running变量，其他线程仅读取变量值，无需加锁，volatile能完美保证多线程间的可见性。

4.2 无锁编程的状态变量

在高性能的无锁编程场景中，volatile常被用于修饰状态标记变量，结合CAS操作实现无锁的线程安全控制。Java并发包中的AQS（AbstractQueuedSynchronizer）、Atomic原子类等核心组件，底层都依赖volatile修饰的状态变量。

以AQS为例，其内部通过volatile修饰的state变量控制同步状态：

private volatile int state;


当线程通过CAS操作修改state变量成功后，后续线程读取state变量时，能看到之前所有的操作结果，基于volatile的happens-before规则，实现无锁的线程安全控制。

4.3 安全发布不可变对象

在多线程场景中，安全发布对象是保证线程安全的关键。对于不可变对象，通过volatile修饰对象引用，可以实现安全的跨线程发布，保证所有线程都能看到正确初始化的不可变对象。

4.4 高性能并发框架中的应用

Java并发包中的大量高性能组件都依赖volatile实现，例如：

• CopyOnWriteArrayList：内部通过volatile修饰数组引用，保证数组修改后的可见性
• ConcurrentHashMap：内部通过volatile修饰节点的val和next变量，实现无锁的并发读操作
• ThreadPoolExecutor：内部通过volatile修饰ctl变量，控制线程池的运行状态，实现无锁的状态检测

五、volatile的常见误区与最佳实践

5.1 四大常见误区拆解

误区一：volatile能保证复合操作的原子性

这是最常见的误区，很多开发者认为给变量添加volatile修饰后，就能保证自增等复合操作的线程安全。实际上，volatile只能保证单次读/写操作的原子性，对于count++这类包含读-改-写的复合操作，volatile无法保证原子性，必须通过synchronized或原子类实现线程安全。

误区二：volatile比synchronized性能差

现代JVM对volatile做了大量优化，volatile的读操作性能和普通变量几乎没有区别，写操作的性能损耗也远低于synchronized。volatile是轻量级的同步机制，不会造成线程阻塞，在适合的场景下，使用volatile能获得比synchronized更好的性能。

误区三：只需要在写变量的地方加volatile，读的地方不需要

volatile的可见性和禁止重排序语义，需要读写两端都使用volatile修饰才能保证。如果只有写操作加了volatile，读操作没有加，JMM无法保证读线程能看到变量的最新值，也无法保证指令重排序的约束，依然会出现线程安全问题。

误区四：volatile修饰的对象引用，能保证对象内部属性的可见性

volatile修饰对象引用时，只能保证引用本身的可见性，无法保证对象内部成员变量的可见性。只有当线程A修改了volatile修饰的对象引用，线程B读取到新的引用后，线程A对对象内部属性的修改才对线程B可见。如果只是修改对象的内部属性，没有修改引用本身，volatile无法保证内部属性的可见性。

5.2 生产环境最佳实践指南

只有同时满足以下所有条件时，才适合使用volatile：

1. 对变量的写操作不依赖于变量的当前值，或者保证只有单线程执行写操作
2. 该变量不会与其他状态变量共同参与不变性约束
3. 访问变量时，没有其他需要加锁的场景

生产环境最佳实践：

1. 优先使用volatile修饰状态标记位，实现线程的启停控制，替代已被废弃的Thread.stop()方法
2. 双重检查锁单例中，必须给实例引用添加volatile修饰，禁止指令重排序
3. 无锁编程场景中，使用volatile修饰状态变量，结合CAS操作实现高性能的线程安全控制
4. 不要使用volatile修饰计数器等需要复合操作的变量，这类场景优先使用Atomic原子类
5. 不要过度使用volatile，只有在明确需要保证可见性和禁止重排序的场景下使用，避免增加代码的理解成本

六、总结

volatile是Java并发编程的基石，它的核心语义是保证多线程间的变量可见性和禁止指令重排序，底层通过内存屏障和MESI缓存一致性协议实现。理解volatile的底层原理，不仅能帮助我们写出线程安全的代码，更能帮助我们理解Java并发包中核心组件的实现逻辑。

在单例模式的架构设计中，volatile是修复DCL单例缺陷的关键，通过禁止对象初始化和引用赋值的重排序，保证多线程场景下不会获取到未初始化的半熟对象，实现高性能、线程安全的懒加载单例。

并发编程的核心，是理解多线程场景下的内存可见性、原子性和有序性问题，而volatile正是解决可见性和有序性问题的轻量级利器。掌握volatile的正确使用方法，避开常见误区，才能在高并发场景下写出稳定、高性能的Java代码。

项目依赖配置

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>

   <groupId>com.jam</groupId>
   <artifactId>volatile-demo</artifactId>
   <version>1.0.0</version>

   <properties>
       <maven.compiler.source>17</maven.compiler.source>
       <maven.compiler.target>17</maven.compiler.target>
       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
       <lombok.version>1.18.30</lombok.version>
       <spring.version>6.1.5</spring.version>
       <guava.version>32.1.3-jre</guava.version>
       <fastjson2.version>2.0.49</fastjson2.version>
       <mybatis-plus.version>3.5.6</mybatis-plus.version>
       <swagger.version>2.5.0</swagger.version>
   </properties>

   <dependencies>
       <dependency>
           <groupId>org.projectlombok</groupId>
           <artifactId>lombok</artifactId>
           <version>${lombok.version}</version>
           <scope>provided</scope>
       </dependency>
       <dependency>
           <groupId>org.springframework</groupId>
           <artifactId>spring-core</artifactId>
           <version>${spring.version}</version>
       </dependency>
       <dependency>
           <groupId>org.springframework</groupId>
           <artifactId>spring-context</artifactId>
           <version>${spring.version}</version>
       </dependency>
       <dependency>
           <groupId>com.google.guava</groupId>
           <artifactId>guava</artifactId>
           <version>${guava.version}</version>
       </dependency>
       <dependency>
           <groupId>com.alibaba.fastjson2</groupId>
           <artifactId>fastjson2</artifactId>
           <version>${fastjson2.version}</version>
       </dependency>
       <dependency>
           <groupId>com.baomidou</groupId>
           <artifactId>mybatis-plus-boot-starter</artifactId>
           <version>${mybatis-plus.version}</version>
       </dependency>
       <dependency>
           <groupId>org.springdoc</groupId>
           <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
           <version>${swagger.version}</version>
       </dependency>
   </dependencies>
</project>