atomic

一、CAS 是什么？ CAS（Compare And Swap），比较并交换，它是一条CPU并发原语。它的功能是判断内存某个位置的值是否为预期值，如果是则更新为新的值，这个过程是原子的。 1 public class CASDemo { 2 public static void main(String[] args) { 3 AtomicInteger atomicInteger = new AtomicInteger(5); 4 5 System.out.print(atomicInteger.compareAndSet(5, 2019)); 6 System.out.println(" the value are " + atomicInteger.get()); 7 8 System.out.print(atomicInteger.compareAndSet(5, 1024)); 9 System.out.println(" the value are " + atomicInteger.get()); 10 } 11 } CAS 并发原语体现在 Java 语言中就是 sun.misc.Unsafe 类中的各个方法。调用 Unsafe 类中的 CAS 方法，JVM 会帮我们实现 CAS 汇编指令。这是一种完全依赖于硬件的功能，通过它实现了原子操作，再次强调，由于CAS

作者：田杰 查询执行时间长引发应用感知 “卡顿” 的场景在数据库的日常支持和使用中并不少见，但由于时区设置引发的 SQL 执行“卡顿”仍然是一个有趣的现象，之前没有具体关注过。 这次客户的细致与坚持让我们找到了问题的源头。 1. 名词解释 序列号 名词 说明 1 CPU 使用率 非空闲的 CPU 时间占比。 2 User CPU 使用率 用户空间（user-space）应用代码消耗的 CPU 时间占比。 3 Sys CPU 使用率 系统空间（sys-space）内核代码消耗 CPU 时间占比。 4 Futex Linux 内核提供的快速用户态锁/信号量；在无竞争场景完全在用户空间中运行，但在存在竞争场景会引发系统调用。 2. 问题现象 客户 MySQL 8.0 实例在 2020-03-19 22:03 ~ 22:04 出现大量活跃连接堆积，慢日志中出现大量低成本查询，并且 CPU 使用率不高但系统 SYS CPU 使用率出现异常波动。 3. 问题排查 3.1 OS 层面 我们来考虑一下有哪些因素可能会导致卡顿： • 物理机 OS 层面波动（通过 IO_WAIT 指标排除）。 • MySQL 自身机制。 3.2 MySQL 层面 排除掉 OS 层面异常类因素，我们开始聚焦在 mysqld 进程调用栈的分析。 为了更好的分析 MySQL 的行为，阿里数据库提供了扁鹊系统来跟踪

1. Atomic java.util.concurrent.atomic提供了一组原子类型操作。如AtomicInteger提供了 int addAndGet(int delta) int incrementAndGet() int get() int compareAndGet() 1.1 无锁线程安全 Atomic类可以实现<font color="blue">无锁（lock-free）的线程安全（thread-safe）访问</font> <p style="color: red;background-color: yellow">原理：CAS（Compare and Set）如果AtomicInteger实例的值是prev，就替换为next，返回true；否则，返回false</p> ```#java /* * 在这个操作中，如果AtomicInteger当前的值是prev，就更新为next，返回true，终止循环； * 如果AtomicInteger当前的值不等于prev，就什么也不做，返回false，继续循环。 */ public int add1AndGet(AtomicInteger var){ int prev, next; do{ prev = var.get(); //之后其他的线程修改了prev的值，也不影响结果 next = prev + 1;

一、源由 我们的程序逻辑经常遇到这样的操作序列： 1、读一个位于memory中的变量的值到寄存器中 2、修改该变量的值（也就是修改寄存器中的值） 3、将寄存器中的数值写回memory中的变量值 如果这个操作序列是串行化的操作（在一个thread中串行执行），那么一切OK，然而，世界总是不能如你所愿。在多CPU体系结构中，运行在两个CPU上的两个内核控制路径同时并行执行上面操作序列，有可能发生下面的场景： CPU1上的操作 CPU2上的操作 读操作 读操作 修改 修改 写操作 写操作 多个CPUs和memory chip是通过总线互联的，在任意时刻，只能有一个总线master设备（例如CPU、DMA controller）访问该Slave设备（在这个场景中，slave设备是RAM chip）。因此，来自两个CPU上的读memory操作被串行化执行，分别获得了同样的旧值。完成修改后，两个CPU都想进行写操作，把修改的值写回到memory。但是，硬件arbiter的限制使得CPU的写回必须是串行化的，因此CPU1首先获得了访问权，进行写回动作，随后，CPU2完成写回动作。在这种情况下，CPU1的对memory的修改被CPU2的操作覆盖了，因此执行结果是错误的。 不仅是多CPU，在单CPU上也会由于有多个内核控制路径的交错而导致上面描述的错误。一个具体的例子如下： 系统调用的控制路径

本节目录 一 锁 二 事务 一 锁 　　行级锁 　　　　select_for_update(nowait=False, skip_locked=False) #注意必须用在事务里面，至于如何开启事务，我们看下面的事务一节。 　　　　返回一个锁住行直到事务结束的查询集，如果数据库支持，它将生成一个 SELECT ... FOR UPDATE 语句。 　　　　举个例子： entries = Entry.objects.select_for_update().filter(author=request.user) #加互斥锁，由于mysql在查询时自动加的是共享锁，所以我们可以手动加上互斥锁。create、update、delete操作时，mysql自动加行级互斥锁 　　　　所有匹配的行将被锁定，直到事务结束。这意味着可以通过锁防止数据被其它事务修改。 　　　　一般情况下如果其他事务锁定了相关行，那么本查询将被阻塞，直到锁被释放。 如果这不想要使查询阻塞的话，使用select_for_update(nowait=True)。 如果其它事务持有冲突的锁，互斥锁, 那么查询将引发 DatabaseError 异常。你也可以使用select_for_update(skip_locked=True)忽略锁定的行。 nowait和　　skip_locked是互斥的