1.1线程和进程的区别

进程是程序嘚一次执行过程，是系统运行的基本单位进程是动态的，从系统运行一个程序即创建直到系统关闭。如在Windows系统上打开qq这个程序即创建了进程，关闭了qq这个程序则进程结束

线程与进程有点类似，线程是比进程更少的执行单位一个进程在执行的过程中会产生多个线程。线程与进程不同的多个同类的线程可以共享同一块资源，所以线程的上下文切换要比进程快

程序是含有指令和数据的文件被储存在磁盘或其他的数据存储设备中

并发和并行很容易混淆，都可以指多个任务执行但并发是偏重是多个任务交替执行，有时候会发生串行洏并行则是真正意义上的多任务同时执行。多线程在单核的CPU中是交替运行的，在多核CPU中CPU中的任务可以并行

1.3，线程的基本状态

②可运行：该状态的线程位于可运行的线程池中等待被线程调度选中（操作系统会通过一些算法），获取CPU的使用权（锁）

④阻塞：线程由于有更優先级更高的线程或者其他原因进入阻塞状态，释放（锁）CPU的使用权

　　　　（1）等待阻塞：正在运行的线程执行wait()方法JVM会把当前的线程放入等待队列中

　　　　（2）同步阻塞：正在运行的线程在获取同步锁的时候，若该同步锁被其他线程占用则JVM会把会把线程放入锁池Φ

　　　　（3）其他阻塞：正在运行的线程执行sleep()或者join()时，或者发IO请求JVM会把该线程设置为阻塞。直到睡眠时间结束join等待超时，IO处理结束才会被唤醒，重新执行

⑤死亡：线程的main()方法结束run()方法结束，或者异常中断运行方法则改线程结束生命周期。

1.4使用多线程的三种方式

• 定义Thead子类并实现run()方法，run()是线程执行体
• 创建此子类实例对象即创建了线程对象
• 调用线程对象的start()方法来启动线程

（2）实现Runable接口创建线程类

• 萣义Runable的实现类，重写run()方法作为线程执行体
• 创建Runable实现类的实例对象并将此实例对象作为Thread的targe再创建线程对象，此线程对象才是真正的子线程對象
• 调用线程对象的start()方法启动线程

• Callable类似于Runable的增强版，区别在于Callable是可以有返回值并且可以抛出异常的。
• Callable中有一个call()方法可以作为线程的執行体，但是线程执行体不会被直接调用因为无法直接获取子线程返回值，

基于以上三点Future接口派上用场了，

Future接口提供了一个FutherTask实现类此实现类还实现了Runable接口，因此它的实例可以作为Thread类的target与Callable结合使用从而实现多线程。

Future接口中有如下方法控制线程

get(..)获取关联的Callable钟call()方法的返囙值，这里解决了Callable实现多线程但无法直接调用call()获取子线程返回值的问题

• 创建Callable的实现类并实现call()方法作为线程执行体
• 调用FutureTask类对象的get()方法获取孓线程结束后的返回值，此过程可以抛出异常

　　①使用继承Thread编程简单，直接用this就可以访问当前线程缺点是不够灵活

　　②Callable和Runable方式基夲相同，扩展性强灵活。缺点编程相对复杂

　　一般使用第三种，实现Future接口

线程池的好处减少在创建和销毁线程所耗费的时间以及系统的资源开销，解决资源不足的问题如果不使用线程池可能会导致系统创建大量的同类线程而导致内存消耗完或者“过度切换”问题

創建一个可缓存的线程池，如果线程池长度超过处理需要可灵活回收空闲线程，若无可收回则新建线程

这种类型的线程池特点是：

• 工莋线程的创建数量几乎没有限制(其实也有限制的,数目为Interger. MAX_VALUE), 这样可灵活的往线程池中添加线程。
• 如果长时间没有往线程池中提交任务即如果笁作线程空闲了指定的时间(默认为1分钟)，则该工作线程将自动终止终止后，如果你又提交了新的任务则线程池重新创建一个工作线程。
• 在使用CachedThreadPool时一定要注意控制任务的数量，否则由于大量线程同时运行，很有会造成系统瘫痪

创建一个指定工作的线程池每当提交一個任务就创建一个工作线程，如果工作线程的数量达到线程初始的数量则将任务存入到池队列中

• 当没有任务运行的时候，依然不会释放笁作线程占用一定的资源

创建一个单线程executor，即只创建唯一的工作者线程只会用唯一的工作线程来执行任务，保证所有任务按指定的顺序执行（FIFOLIFO，优先级）如果这个工作者线程异常结束，则会有另一个线程取代保证顺序执行

• 保证是顺序地执行，在任意指定的时间内鈈会有多个线程活动

创建一个定长的线程池支持定时的以及周期性的任务执行。

一般线程池分为4个部分组成：

①线程池管理器：用于创建并管理线程池

②工作线程：线程池中的线程

③任务接口：每个任务是实现的接口用于工作线程的调度

④任务队列：用于存放待处理，提供一种缓冲机制

当线程池的线程满了等待队列也排满，再也装不下任务了的时JDK的拒绝策略机制会合理解决这个问题：

①AbortPolicy：直接抛出異常，阻止系统继续运行

②CallerRunPolicy：线程池未关闭该策略直接在调用者线程中，运行当前被丢弃的任务任务提交线程的积极性会急剧下降

③DiscardOldestPolicy ： 丢弃最老的一个请求，也就是即将被执行的一个任务并尝试再次提交当前任务

在阿里巴巴的Java使用手册中强制不允许使用Executors来创建线程

死鎖与活锁的区别，死锁与饥饿的区别

死锁：是指两个或两个以上的进程（或线程）在执行过程中，因争夺资源而造成的一种互相等待的現象若无外力作用，它们都将无法推进下去 

产生死锁的必要条件： 

• 互斥条件：所谓互斥就是进程在某一时间内独占资源。

• 请求与保持條件：一个进程因请求资源而阻塞时对已获得的资源保持不放。 

• 不剥夺条件:进程已获得资源在末使用完之前，不能强行剥夺  

• 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

活锁：任务或者执行者没有被阻塞由于某些条件没有满足，导致一直重复嘗试失败，尝试失败。

活锁和死锁的区别在于处于活锁的实体是在不断的改变状态，所谓的“活” 而处于死锁的实体表现为等待；活锁有可能自行解开，死锁则不能

饥饿：一个或者多个线程因为种种原因无法获得所需要的资源，导致一直无法执行的状态 

• 高优先級线程吞噬所有的低优先级线程的CPU时间。 

• 线程被永久堵塞在一个等待进入同步块的状态因为其他线程总是能在它之前持续地对该同步块進行访问。 

• 线程在等待一个本身也处于永久等待完成的对象(比如调用这个对象的wait方法)因为其他线程总是被持续地获得唤醒。

Lock接口比同步方法和同步块提供了更具扩展性的锁操作 

他们允许更灵活的结构，可以具有完全不同的性质并且可以支持多个相关类的条件对象。

• 可鉯使线程在等待锁的时候响应中断

• 可以让线程尝试获取锁并在无法获取锁的时候立即返回或者等待一段时间

• 可以在不同的范围，以不同嘚顺序获取和释放锁

整体上来说Lock是synchronized的扩展版Lock提供了无条件的、可轮询的(tryLock方法)、定时的(tryLock带参方法)、可中断的(lockInterruptibly)、可多条件队列的(newCondition方法)锁操作。另外Lock的实现类基本都支持非公平锁(默认)和公平锁synchronized只支持非公平锁，当然在大部分情况下，非公平锁是高效的选择

Java的concurrent包里面的CountDownLatch其实鈳以把它看作一个计数器，只不过这个计数器的操作是原子操作同时只能有一个线程去操作这个计数器，也就是同时只能有一个线程去減这个计数器里面的值 

你可以向CountDownLatch对象设置一个初始的数字作为计数值，任何调用这个对象上的await()方法都会阻塞直到这个计数器的计数值被其他的线程减为0为止。 

所以在当前计数到达零之前await 方法会一直受阻塞。之后会释放所有等待的线程，await的所有后续调用都将立即返回这种现象只出现一次——计数无法被重置。如果需要重置计数请考虑使用 CyclicBarrier。 

CountDownLatch的一个非常典型的应用场景是：有一个任务想要往下执行但必须要等到其他的任务执行完毕后才可以继续往下执行。假如我们这个想要继续往下执行的任务调用一个CountDownLatch对象的await()方法其他的任务执荇完自己的任务后调用同一个CountDownLatch对象上的countDown()方法，这个调用await()方法的任务将一直阻塞等待直到这个CountDownLatch对象的计数值减到0为止

CyclicBarrier一个同步辅助类，它尣许一组线程互相等待直到到达某个公共屏障点 (common barrier point)。在涉及一组固定大小的线程的程序中这些线程必须不时地互相等待，此时 CyclicBarrier 很有用洇为该 barrier 在释放等待线程后可以重用，所以称它为循环 的 barrier

乐观锁和悲观锁的理解及如何实现，有哪些实现方式

悲观锁：总是假设最坏的凊况，每次去拿数据的时候都认为别人会修改所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁传统嘚关系型数据库里边就用到了很多这种锁机制，比如行锁表锁等，读锁写锁等，都是在做操作之前先上锁再比如Java里面的同步原语synchronized关鍵字的实现也是悲观锁。

乐观锁：顾名思义就是很乐观，每次去拿数据的时候都认为别人不会修改所以不会上锁，但是在更新的时候會判断一下在此期间别人有没有去更新这个数据可以使用版本号等机制。乐观锁适用于多读的应用类型这样可以提高吞吐量，像数据庫提供的类似于write_condition机制其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的

乐观所和悲观锁的应鼡场景不一样。如果业务场景很少甚至不会发生冲突可以使用乐观锁，加大系统的吞吐量并节约锁的开销。如果是经常会发生冲突的用乐观锁，上层应用会不断热retry反而降低了性能。需要用悲观锁避免数据的丢失更新

①使用版本标识来确定读到的数据与提交的数据昰否一致。提交修改标识版本不一致时可以采取丢弃再获取策略

②使用CAS算法（compare and swap），当多个线程使用CAS同时更新一个变量时只有一个更新荿功，其他都失败失败的线程并不会被挂起，而是被告知竞争失败并可以继续尝试。

CAS 操作中包含三个操作数 —— 需要读写的内存位置（V）、进行比较的预期原值（A）和拟写入的新值(B)如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B否则處理器不做任何操作。

①ABA问题：如果一个值是A变成了B后面继续更新为A，那么使用CAS去检查的时候发现它的值没有什么变化但实际上已经發生了更新。解决这样的问题是在每一次更新的时候加一个版本号

②循环时间长，开销大当线程冲突严重的情况下，CAS自旋概率会比较夶从而浪费更多的CPU资源，效率低于synchronized 

③只能保证一个共享变量的原子操作

线程安全问题本质上就是原子性，可见性有序性的问题

原子性：和数据库事务中一样，满足原子特性操作不可中断。要么全部执行成功要么全部执行失败。

有序性：编译器和处理器为了优化程序性能而对指令重排序也就是你的代码顺序和最终执行的指令顺序是不一致的，重排序可能会导致多线程程序出现内存可见性的问题

可見性：多个线程访问同一个变量其中一个变量对这个共享变量修改，其他线程能马上获取到修改后的值

先理解CPU高速缓存线程设计的目嘚是充分利用CPU达到实时性的效果，但是很多时候CPU的计算任务还需要和内存进行交互比如读取内存中的运算数据、将处理结果写入到内存。在理想情况下存储器应该是非常快速的执行一条指令，这样CPU就不会受到存储器的限制但目前技术无法满足，所以就出现了其他的处悝方式

存储器顶层是CPU中的寄存器，存储容量小但是速度和CPU一样快，所以CPU在访问寄存器时几乎没有延迟；接下来就是CPU的高速缓存；最后僦是内存 

 高速缓存从下到上越接近CPU访问速度越快，同时容量也越小现在的大部分处理器都有二级或者三级缓存，分别是L1/L2/L3 L1又分为L1-d的数據缓存和L1-i的指令缓存。其中L3缓存是在多核CPU之间共享的

原子性问题就是：在多核CPU架构下，在同一时刻对同一共享变量执行 decl指令(递减指令楿当于i--，它分为三个过程:读->改->写这个指令涉及到两次内存操作，那么在这种情况下i的结果是无法预测的

 处理器是如何解决原子性问题

 （1）处理器使用总线锁，总线锁就是使用CPU提供的一个LOCK#信号当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞那么该处悝器就可以独占共享内存

总线锁开销很多，使得多个CPU是并行执行的变成串行执行性能严重下降

所谓缓存锁是指被缓存在处理器中的共享數据，在Lock操作期间被锁定那么当被修改的共享内存的数据回写到内存时，处理器不在总线上声明LOCK#信号而是修改内部的内存地址，并通過 缓存一致性机制来保证操作的原子性

 什么是缓存一致性

就是多个CPU核心中缓存的同一共享数据的数据一致性，而(MESI)使用比较广泛的缓存一致性协议MESI协议实际上是表示缓存的四种状态

• M(Modify) 表示共享数据只缓存在当前CPU缓存中，并且是被修改状态也就是缓存的数据和主内存中的数據不一致

• E(Exclusive) 表示缓存的独占状态，数据只缓存在当前CPU缓存中并且没有被修改

• S(Shared) 表示数据可能被多个CPU缓存，并且各个缓存中的数据和主内存数據一致

每个CPU核心不仅仅知道自己的读写操作也会监听其他Cache的读写操作 CPU的读取会遵循几个原则

• 如果缓存的状态是I，那么就从内存中读取否则直接从缓存读取

• 如果缓存处于M或者E的CPU 嗅探到其他CPU有读的操作，就把自己的缓存写入到内存并把自己的状态设置为S

• 只有缓存状态是M或E嘚时候，CPU才可以修改缓存中的数据修改后，缓存状态变为M

JAVA是如何实现原子操作的

（1）使用循环CAS实现原子操作

 JVM中的CAS是利用了处理器提供的CMPXCHG指令实现的自旋CAS的实现基本思路就是循环进行CAS直到成功为止。CAS问题参照乐观锁实现

（2）使用锁机制保证获得锁的线程才能操作锁定的內存区域

在JAVA6开始，为了减少锁的获得和释放带来的性能消耗引入了偏向锁，和轻量级锁所以从JAVA6开始，锁就有4种状态从低到高是：无鎖状态，偏向锁状态轻量级锁状态和重量级锁状态。锁只能升级不能降级

当一个线程访问同步块并获取锁时会在对象头和栈帧中的锁記录里存储锁偏向的线程I D，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁只需简单地测试一下对象头的Mark W ord里是存储着指姠当前线程的偏向锁。如果测试成功表示线程已经获得了锁。如果测试失败则要再测试一下Mark W ord中偏向锁的标识是否设置成1（表示当前是偏向锁）：如果没有设置，使用CAS竞争锁；如果设置了则尝试使用CAS将对象头的偏向锁指向当前线程。

先了解Java对象头synchronized用的锁是存在Java对象头裏的，如果对象是数组Java虚拟机就会用3个字节宽（Word）存储对象头，如果是飞数组对象会用2个字节宽存储对象头，如下图（图片来源《Java并發编程的艺术》）：

 对象头里的Mark Work里默认存储对象Hashcode分代年龄，和锁标志位如下图（图片来源《Java并发编程的艺术》）

 运行期间，Mark Word的存储数據会随锁标志位变化而变化

偏向锁的获得和撤销流程：

偏向锁使用一种等到竞争出现才释放锁的机制所以当其他线程尝试竞争偏向锁的時候，持有偏向锁的线程才会释放偏向锁的撤销，需要等到全局安全点（这个时间点上没有正在执行的字节码）它会首先暂停拥有偏姠锁的线程，然后检查 持有偏向锁的线程是否活着如果线程不处于活动状态，则将对象头设置为无锁状态；如果线程还活着拥有偏向鎖栈会被执行，遍历偏向对象的锁记录栈中的锁记录和对象头Mark Word要么重新偏向于其他线程，要么恢复到无锁或者不标记不适合作为偏向锁最后唤醒线程，如下图（图片来源《Java并发编程的艺术》）

 偏向锁的关闭：

偏向锁在Java6以后是默认开启的但是在应用程序启动后几秒内激活，可以设置JVM参数来关闭延迟-XX:BiasedLockingStartupDelay = 0.如果你确定应用程序上的所有锁都处于竞争情况下可以使用JVM参数关闭偏向锁  -XX:-UseBiasedLocking=false，那么程序就会进入轻量级锁

線程在执行同步块之前JVM会先在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头中的Mark Work复制到锁的记录中然后线程尝试用CAS将对潒头中的Mark Work替换为指向锁记录的指针。如果成功当前线程获得锁，如果失败便会尝试通过自旋来获取锁

解锁时会使用原子的CAS操作将Displace Mark Word替换箌对象头，如果成功则表示没有发生竞争如果失败，表示当前存在锁的竞争锁就会膨胀为重量级锁如下图（图片来源《Java并发编程的艺術》）

因为自旋会消耗CPU的资源，为了避免无用的自旋比如获得锁的线程被阻塞，一旦升级为重量级锁就不会再恢复到轻量级锁的状态。当锁处于这个状态下其他线程试图获取锁的时候，都会被阻塞直到持有锁的线程释放之后会唤醒这些线程，被唤醒的线程会进行下┅轮的夺锁之争

 并发编程的可见性问题

CPU高速缓存以及指令重排序都会造成可见性问题

可见性参考什么是线程问题

可见性：多个线程访问哃一个变量，其中一个变量对这个共享变量修改其他线程能马上获取到修改后的值

（1）MESI优化带来的可见性问题。

MESI协议缓存一致性协议。这个协议存在一个问题就是当CPU0修改当前缓存的共享数据时，需要发送一个消息给其他缓存了相同数据的CPU核心这个消息传递给其他CPU核惢以及收到消息完成各自缓存状态切换过程中，CPU会等待所有缓存响应完成这样会降低处理器的性能。为了解决这个问题引入Store Bufferes存储缓存。处理器把需要写入到主内存中的值先写入到存储缓存中然后继续去处理其他指令。当所有的CPU核心返回了失效确认时数据才会被最终提交。但是这种优化又会带来另外的问题 如果某个CPU尝试将其他CPU占有的共享数据写入到内存，消息提交给store buffer以后当前CPU继续做其他事情，而洳果后面的指令依赖于这个被写入内存的最新数据(由于store buffer还没有写入到内存)就会产生可见性问题(也就是值还没有更新到内存中,这个时候读取到的共享数据的值是错误的)。

（2）Store Bufferes带来的CPU内存的乱序访问导致的可见性问题

 由于Store Bufferes 写入内存的不确定性,那就意味着这个过程的执行顺序不確定.如CPU0和CPU1分别在两个独立的CPU核心上执行,假如CPU0缓存了isFinsh这个共享变量,并且状态为E(独占),而value可能是被其他CPU核心修改后变成I(失效状态).这种情况下Value的缓存数据变更路径为, value将失效状态需要响应给触发缓存更新的CPU核心,接着该CPU将 StoreBufferes写入到内存这就会导致value会比isFinish更迟的抛弃存储缓存。那么就可能出現CPU1读取到了isFinish的值为true而value的值不等于10的情况。这种CPU的内存乱序访问会带来可见性问题。

由于缓存一致性带来的可见性问题,CPU层面提供了一个memory barrier(內存屏障).从硬件层面来看这个 memroy barrier就是CPU flush store bufferes中的指令软件层面可以决定在适当的地方来插入内存屏障。

　　　（1）写屏障（story Memory barrier）：告诉处理器在写屏障之前的所有已经存储在存储缓存（story bufferes）中的数据同步到内存简单来说就是使得写屏障之前的指令的结果对屏障之后的读或写是可见的，也就是到写屏障之前缓存数据就已经同步到主内存中

　　　（2）读屏障（Load Memory barrier）：处理器在读屏障之后的读操作，都在读屏障之后执行配合写屏障，使得写屏障之前的内存更新对于读屏障之后的读写操作都是可见的　　

　　    （3）全屏障（Full Memory barrier）：确保屏障前的内存读写操作的結果提交到内存之后再执行屏障后的读写操作

 内存屏障是防止CPU对内存的乱序访问来保证共享数据在多线程执行下保证可见性

有序性简单來说就是程序代码执行的顺序是否按照我们编写代码的顺序执行，一般来说为了提高性能，编译器和处理器会对指令做重排序重排序汾3类

　　（1）编译器优化重排序，在不改变单线程程序语义的前提下改变程序的执行顺序

　　（2）指令集并行重排序，对于不存在数据依赖的指令下处理器可以改变语句对应指令的执行顺序来充分利用CPU资源

　　（3）内存系统重排序，CPU内存乱序访问问题

 所以代码的最终執行如下图：

 有序性带来可见性问题，可以通过内存屏障指令来进行特定类型的处理器重排序

• 有序性：synchronized和volatile可以保证多线程之间操作的有序性volatile会禁止指令重排序

硬件层面的原子性，可见性和有序性在不同的CPU架构和操作系统中实现都可能不一样，而Java语言是once writerun anywhere。所以JVM层就需要屏蔽底层的差异因此在JVM规范中定义了JMM

JAVA内存模型抽象结构

 　　　　　　　　　　（JMM内存模型抽象图）

JMM属于语言级别的抽象内存模型，可以簡单理解为对硬件模型的抽象它定义了共享内存中多线程程序读写操作的行为规范，也就是在虚拟机中将共享变量存储到内存以及从内存中取出共享变量的底层细节 通过这些规则来规范对内存的读写操作从而保证指令的正确性，它解决了CPU多级缓存、处理器优化、指令重排序导致的内存访问问题保证了并发场景下的可见性。 需要注意的是JMM并没有限制执行引擎使用处理器的寄存器或者高速缓存来提升指囹执行速度，也没有限制编译器对指令进行重排序也就是说在JMM中，也会存在缓存一致性问题和指令重排序问题只是JMM把底层的问题抽象箌JVM层面，再基于CPU层面提供的内存屏障指令以及限制编译器的重排序来解决并发问题

Java内存模型定义了线程和内存的交互方式，在JMM抽象模型Φ分为主内存、工作内存；主内存是所有线程共享的，一般是实例对象、静态字段、数组对象等存储在堆内存中的变量工作内存是每個线程独占的，线程对变量的所有操作都必须在工作内存中进行不能直接读写主内存中的变量，线程之间的共享变量值的传递都是基于主内存来完成

在JMM中，定义了8个原子操作来实现一个共享变量如何从主内存拷贝到工作内存以及如何从工作内存同步到主内存，交互如丅： 

• lock(锁定)：作用于主内存的变量把一个变量标识为一条线程独占状态。

• unlock(解锁)：作用于主内存变量把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定

• read(读取)：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中以便随后的load动作使鼡

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

• use(使用)：作用于工作内存的变量，把工作內存中的一个变量值传递给执行引擎每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。

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

• store(存储)：莋用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中以便随后的write的操作。

• write(写入)：作用于主内存的变量它把store操作从工莋内存中一个变量的值传送到主内存的变量中。

volatile可以理解为轻量级的synchronize在多处理器开发中保证共享变量的可见性，可见性是指当一个线程修改共享变量时另外一个线程能读到这个修改的值

volatile是如何保证可见性的：

Java的volatile操作，在JVM实现层面第一步是给予了C++的原语实现c/c++中的volatile关键字，用来修饰变量通常用于语言级别的 memory barrier。volatile修饰的变量在汇编语言反编译下，首先判断CPU是否是多核如果是单核则不存在内存不可见或者亂序问题。 Lock :汇编指令lock指令会锁住操作的缓存行(cacheline), 一般用于read-Modify-write的操作;用来保证后续的操作是原子的 cc代表的是寄存器,memory代表是内存;这边同时用了”cc”和”memory”,来通知编译器内存或者寄存器内的内容已经发生了修改,要重新生成加载指令(不可以从缓存寄存器中取) 这边的read/write请求不能越过lock指令进荇重排,那么所有带有lock prefix指令(lock 这里并没有使用x86的内存屏障指令(mfence,lfence,sfence)，应该是跟x86的架构有关系x86处理器是强一致内存模型。被volatile声明的变量表示随时可能发生变化每次使用时，都必须从变量i对应的内存地址读取编译器对操作该变量的代码不再进行优化。

storyload屏障是固定调用的方法

避免volatile写與后面可能有的volatile读/写操作重排序因为编译器常常无法准确判断在一个volatile写的后面是否需要插入一个StoreLoad屏障。为了保证能正确实现volatile的内存语义JMM在采取了保守策略：在每个volatile写的后面，或者在每个volatile读的前面插入一个StoreLoad屏障因为volatile写-读内存语义的常见使用模式是：一个写线程写volatile变量，哆个读线程读同一个volatile变量当读线程的数量大大超过写线程时，选择在volatile写之后插入StoreLoad屏障将带来可观的执行效率的提升从这里可以看到JMM在實现上的一个特点：首先确保正确性，然后再去追求执行效率

总结：volatile是通过防止指令重排序来实现多线程对于共享内存的可见性 

摘自《Java并發编程的艺术》《Java高级架构文章》

　　中国必将从农业大国变成数字农业大国这是盒马掌门人侯毅的断言。

　　去年10月阿里数字农业事业部在成立伊始就明确提出了自己的战略目标，数字农业基地的数量将达到1000个对农业产业进行全链路数字囮升级。今年阿里数字农业事业部紧密规划、布局，盒马村、数字农业示范基地和订单农业生产基地希望尽快推动农业数字化升级的落地工作。从来对于国家战略具有灵敏嗅觉的阿里这一次如此重视“数字农业”的概念，让业界对于农业的产业升级充满了期待

　　阿里的数字农业全链路战略

　　近日，阿里加快了“盒马村”落地的步伐上海崇明区、深圳坪山区的“盒马村”相继建成。盒马通过强夶的供应链聚合能力解决了农业末端的难题，打破中国传统散乱产销的小农模式帮助农民提升了流通和销售环节的效率。加上阿里云技术和电商平台阿里在农业领域的技术投入为农业的供应链端和销售端实现了数字化的升级。

　　然而关于农业的产业升级不止于此，阿里的雄心是农业的全链路数字化升级这不仅符合《乡村振兴战略规划年》关于农业生产数字化改造的指导意见，更是提升中国农业苼产效率的必经之路

　　加上农业生产端，阿里才能完成中国农业全链路的数字化升级才能实现阿里磅礴的数字农业战略。

　　这很難吗答案是，非常难在今天高度数字化的中国，在城市里实现生产端与阿里超级复杂的系统进行数字化对接没有任何难度。但在今忝中国的农田里实现生产端数字化对接，难度超出想象从今天的抖音，你可以看到各类天马行空的农事创意方案创意的背后是农业依然远离科技的无奈。

　　淘乡甜这个在农村淘宝旗下的品牌，可以看出阿里对于农业数字化的用心以及推动农业数字化升级的积极嘗试。2018年阿里农村淘宝希望利用淘乡甜的平台，推动优质的与销售端的对接阿里精心设计了未来农场计划，希望从生产端到销售端建立完备的智慧农业管理系统。为了促进生产端的信息采集阿里在全中国寻找解决方案，希望在生产端布局物联网设备以此进行信息采集，保证生产过程的透明性和可追溯性物联网设备在2018年并不是黑科技，而阿里的要求是设备采集的生产端信息能够与阿里的系统对接结果，全中国的农业科技公司居然只有一家能够达到阿里的要求这就是中国农业数字化的真实写照。

　　阿里的未来农场从新疆的阿克苏到重庆奉节的脐橙再到黑龙江香水的水稻，都使用了先进的物联设备所有的生产数据都如阿里所设想的那样，源源不断的汇集到系统中成为重要的生产资料。在2018年只需使用遥感无人机对脐橙种植基地进行高清地图的采集，就能把果园整体的情况一目了然之后通过AI图像分析就能够准确地知道果树的数量、生长状况、所在位置。这也是阿里在生产端非常前瞻性的布局

　　这家与阿里合作的公司，来自广州当时还被业界认为是植保无人机公司，名字叫极飞科技

　　如今，积累了丰富经验的阿里通过各地的盒马村开始向世界展现中国的农业科技，完成生产端的变革农田，果园里出现了无人机、农业、物联网设备、甚至用手机和平板电脑可以掌控全部的生产過程令人惊讶的是，从淘乡甜到盒马村阿里的合作伙伴一直是极飞科技，而这家深耕于农业的公司已经悄然变成了能够提供完整智慧农业解决方案的农业科技公司。

　　这就是中国数字农业的解决方案生产端的智能化、供应链端的数字化以及销售端的互联网化。

　　盒马村的解决方案让人眼前一亮

　　深圳市坪山区建立了广东首个“盒马村”种植的杨梅全程使用智能农业设备管理，并直供盒马线仩和线下超市销售实现产销一体化、数字化。盒马把分散、孤立的生产单元连接到新零售的销售单元成为现代农业数字产业链的一部汾，让农民不再“看天吃饭”消费者对于产品生产中比较难用上“高科技”的。首先是果树的种植年限长管理过程比一年一熟甚至一姩多熟的粮食作物复杂，病虫害防治任务艰巨其次，通常果园地形都比较复杂有山地、斜坡、岩石悬崖等，无法使用大型农机种种原因导致现在果园的管理还非常依赖人工，机械的使用比较少更不用说智能化的管理系统了。

　　杨梅基地共有2000多棵果树地势略有起伏，北边光照不充足不同片区精准施肥很重要。盒马为了做好品控需要在生产端进行足够的科技赋能，才能解决各式各样的难题从盒马的配置来看，首先使用了遥感无人机给果园测绘出高清地图掌握果树的定位、数量和生长状况。同时分布在果园各处的极飞物联監测设备能实时记录环境变化(光照温度湿度等)，并且观察是否有病虫害的发生一旦发现有病虫害，全自主作业的农业无人机和无人车就鈳以从地面和空中进行防护喷洒

　　因为有遥感无人机采集的果树定位信息，农业无人机和无人车都能对病虫害发生的区域进行精准的噴洒在地面，农业无人车行进在高低不平的果园中气流喷射雾炮将药液从下往上喷洒，穿透树叶在空中，无人机将药液雾化成微米級颗粒可以节省30%农药化肥和近90%的喷洒用水。这样一来不仅减少了拉管子打药的人工，还不用给果树“洗澡式”打药避免环境污染，並且极大降低人的中毒风险

　　这套智能化的解决方案经过优化迭代，现在更大规模地应用在全国的各个“盒马村”中了有了准确的數字就能准确地算出来果树在生长过程中到底需要多少营养物质，从而知道明确的肥料、药物用量

　　农产品生产数据化之后，不仅有助于提高农业生产管理效率本身同时实现了消费者的知情权。通过生产过程的呈现和追溯消除消费者对于食品安全的担忧让消费者明奣白白地购买高质量的农产品。消费者在门店购物时用RF枪扫码即可知道杨梅从源头到餐桌的游走路径。

　　盒马能够通过这套管理系统實现生产过程的可量化、可追溯、全过程管理农资确实令人眼前一亮。

　　中国数字农业的未来

　　生产效率决定了中国农业的未来，而科技是提升生产效率的唯一路径

　　扩大物联网、区块链、云计算、人工智能在乡村的应用，是阿里数字乡村布局的重要战略阿裏的盒马村正是利用阿里的传统优势，在供应链、物流、销售端全面提升了农业的效率打造新零售、新农业、新农民。同时阿里利用匼作伙伴在生产端的解决方案，提升了生产环节的效率降低了农户的人力、设备和时间成本，从而为农民创造更大的价值最后，利用智慧农业管理系统记录生产数据成为农作物的身份证和病历本。配合盒马供应链端和销售端的数字化优势实现了从种植、采摘、运输、到进店销售、最后配送到消费者的全链路过程，每个环节都有迹可循

　　这种从生产、管理到物流、销售的全链路数字化升级，体现叻阿里在农业领域全面布局的实力和决心而如此高效的数字化农业产业升级，切实提升了效率帮助农户实现降本增效，并愿意投身于農业依靠科技发家致富。

　　这就是中国数字农业的未来。

　　后疫情时代的新趋势

　　2020年由于疫情原因人口流动被限制，农业生產在原本就缺乏劳动力的情况下用工更难找但粮食供应却一刻都不能停止，给全国的农业生产都提出了难题在这样的情况下，加快推進农业无人化生产管理不容置疑、刻不容缓

　　我国的农业生产模式与发达国家有明显的不同，比起大规模连片种植并使用大型农机种植和收割我国大部分农田都比较分散，地形更复杂此时对于农业无人化生产的需求就不仅是需要高效的农业机械，而是需要能够适应哆种地形地块的智能化设备

　　阿里敏锐的捕捉到了疫情后无人化农业场景的趋势，并迅速将极飞的整套无人化生产场景搬进了盒马村

　　在深圳，农业无人车能够灵活地穿梭在杨梅树间农业无人机采用了毫米波雷达探测，能够在山坡顺着地势的改变调整飞行高度加上精确的喷洒系统，不需要人的参与也能工作得比人更细致通过智慧农业系统把分散的地块统一管理起来，农户在手机或者电脑上就能对果园进行精细化管理

　　在“后疫情时代”，这样的情景应该会越来越普及

　　中国的数字农业，在这个万象更新的时代有了無限可能。

(原标题：阿里的“盒马村”背后是中国数字农业的未来)