多线程操作共享资源保证原子，线程不共享的资源有哪些

大家好，今天来为大家解答多线程操作共享资源保证原子这个问题的一些问题点，包括线程不共享的资源有哪些也一样很多人还不知道，因此呢，今天就来为大家分析分析，现在让我们一起来看看吧！如果解决了您的问题，还望您关注下本站哦，谢谢~

setifabsent是原子操作吗

setifabsent是原子操作，

"原子操作(atomicoperation)是不需要synchronized"，这是多线程编程的老生常谈了。所谓原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何contextswitch（切换到另一个线程）。

Java多线程同步内部如何实现的

提示

请带着这些问题继续后文，会很大程度上帮助你更好的理解相关知识点。@pdai

为什么要有线程池?Java是实现和管理线程池有哪些方式?请简单举例如何使用。为什么很多公司不允许使用Executors去创建线程池?那么推荐怎么使用呢?ThreadPoolExecutor有哪些核心的配置参数?请简要说明ThreadPoolExecutor可以创建哪是哪三种线程池呢?当队列满了并且worker的数量达到maxSize的时候，会怎么样?说说ThreadPoolExecutor有哪些RejectedExecutionHandler策略?默认是什么策略?简要说下线程池的任务执行机制?execute–>addWorker–>runworker(getTask)线程池中任务是如何提交的?线程池中任务是如何关闭的?在配置线程池的时候需要考虑哪些配置因素?如何监控线程池的状态?为什么要有线程池

线程池能够对线程进行统一分配，调优和监控:

降低资源消耗(线程无限制地创建，然后使用完毕后销毁)提高响应速度(无须创建线程)提高线程的可管理性ThreadPoolExecutor例子

Java是如何实现和管理线程池的?

从JDK5开始，把工作单元与执行机制分离开来，工作单元包括Runnable和Callable，而执行机制由Executor框架提供。

WorkerThread

SimpleThreadPool

程序中我们创建了固定大小为五个工作线程的线程池。然后分配给线程池十个工作，因为线程池大小为五，它将启动五个工作线程先处理五个工作，其他的工作则处于等待状态，一旦有工作完成，空闲下来工作线程就会捡取等待队列里的其他工作进行执行。

这里是以上程序的输出。

输出表明线程池中至始至终只有五个名为"pool-1-thread-1"到"pool-1-thread-5"的五个线程，这五个线程不随着工作的完成而消亡，会一直存在，并负责执行分配给线程池的任务，直到线程池消亡。

Executors类提供了使用了ThreadPoolExecutor的简单的ExecutorService实现，但是ThreadPoolExecutor提供的功能远不止于此。我们可以在创建ThreadPoolExecutor实例时指定活动线程的数量，我们也可以限制线程池的大小并且创建我们自己的RejectedExecutionHandler实现来处理不能适应工作队列的工作。

这里是我们自定义的RejectedExecutionHandler接口的实现。

RejectedExecutionHandlerImpl.java

ThreadPoolExecutor提供了一些方法，我们可以使用这些方法来查询executor的当前状态，线程池大小，活动线程数量以及任务数量。因此我是用来一个监控线程在特定的时间间隔内打印executor信息。

MyMonitorThread.java

这里是使用ThreadPoolExecutor的线程池实现例子。

WorkerPool.java

注意在初始化ThreadPoolExecutor时，我们保持初始池大小为2，最大池大小为4而工作队列大小为2。因此如果已经有四个正在执行的任务而此时分配来更多任务的话，工作队列将仅仅保留他们(新任务)中的两个，其他的将会被RejectedExecutionHandlerImpl处理。

上面程序的输出可以证实以上观点。

注意executor的活动任务、完成任务以及所有完成任务，这些数量上的变化。我们可以调用shutdown()方法来结束所有提交的任务并终止线程池。

ThreadPoolExecutor使用详解

其实java线程池的实现原理很简单，说白了就是一个线程集合workerSet和一个阻塞队列workQueue。当用户向线程池提交一个任务(也就是线程)时，线程池会先将任务放入workQueue中。workerSet中的线程会不断的从workQueue中获取线程然后执行。当workQueue中没有任务的时候，worker就会阻塞，直到队列中有任务了就取出来继续执行。

Execute原理

当一个任务提交至线程池之后:

线程池首先当前运行的线程数量是否少于corePoolSize。如果是，则创建一个新的工作线程来执行任务。如果都在执行任务，则进入2.判断BlockingQueue是否已经满了，倘若还没有满，则将线程放入BlockingQueue。否则进入3.如果创建一个新的工作线程将使当前运行的线程数量超过maximumPoolSize，则交给RejectedExecutionHandler来处理任务。

当ThreadPoolExecutor创建新线程时，通过CAS来更新线程池的状态ctl.

参数corePoolSize线程池中的核心线程数，当提交一个任务时，线程池创建一个新线程执行任务，直到当前线程数等于corePoolSize,即使有其他空闲线程能够执行新来的任务,也会继续创建线程；如果当前线程数为corePoolSize，继续提交的任务被保存到阻塞队列中，等待被执行；如果执行了线程池的prestartAllCoreThreads()方法，线程池会提前创建并启动所有核心线程。workQueue用来保存等待被执行的任务的阻塞队列.在JDK中提供了如下阻塞队列:具体可以参考JUC集合:BlockQueue详解ArrayBlockingQueue:基于数组结构的有界阻塞队列，按FIFO排序任务；LinkedBlockingQueue:基于链表结构的阻塞队列，按FIFO排序任务，吞吐量通常要高于ArrayBlockingQueue；SynchronousQueue:一个不存储元素的阻塞队列，每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQueue；PriorityBlockingQueue:具有优先级的无界阻塞队列；

LinkedBlockingQueue比ArrayBlockingQueue在插入删除节点性能方面更优，但是二者在put(),take()任务的时均需要加锁，SynchronousQueue使用无锁算法，根据节点的状态判断执行，而不需要用到锁，其核心是Transfer.transfer().

maximumPoolSize线程池中允许的最大线程数。如果当前阻塞队列满了，且继续提交任务，则创建新的线程执行任务，前提是当前线程数小于maximumPoolSize；当阻塞队列是无界队列,则maximumPoolSize则不起作用,因为无法提交至核心线程池的线程会一直持续地放入workQueue.keepAliveTime线程空闲时的存活时间，即当线程没有任务执行时，该线程继续存活的时间；默认情况下，该参数只在线程数大于corePoolSize时才有用,超过这个时间的空闲线程将被终止；unitkeepAliveTime的单位threadFactory创建线程的工厂，通过自定义的线程工厂可以给每个新建的线程设置一个具有识别度的线程名。默认为DefaultThreadFactoryhandler线程池的饱和策略，当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了4种策略:AbortPolicy:直接抛出异常，默认策略；CallerRunsPolicy:用调用者所在的线程来执行任务；DiscardOldestPolicy:丢弃阻塞队列中靠最前的任务，并执行当前任务；DiscardPolicy:直接丢弃任务；

当然也可以根据应用场景实现RejectedExecutionHandler接口，自定义饱和策略，如记录日志或持久化存储不能处理的任务。

三种类型newFixedThreadPool

线程池的线程数量达corePoolSize后，即使线程池没有可执行任务时，也不会释放线程。

FixedThreadPool的工作队列为无界队列LinkedBlockingQueue(队列容量为Integer.MAX_VALUE),这会导致以下问题:

线程池里的线程数量不超过corePoolSize,这导致了maximumPoolSize和keepAliveTime将会是个无用参数由于使用了无界队列,所以FixedThreadPool永远不会拒绝,即饱和策略失效newSingleThreadExecutor

初始化的线程池中只有一个线程，如果该线程异常结束，会重新创建一个新的线程继续执行任务，唯一的线程可以保证所提交任务的顺序执行.

由于使用了无界队列,所以SingleThreadPool永远不会拒绝,即饱和策略失效

newCachedThreadPool

线程池的线程数可达到Integer.MAX_VALUE，即2147483647，内部使用SynchronousQueue作为阻塞队列；和newFixedThreadPool创建的线程池不同，newCachedThreadPool在没有任务执行时，当线程的空闲时间超过keepAliveTime，会自动释放线程资源，当提交新任务时，如果没有空闲线程，则创建新线程执行任务，会导致一定的系统开销；执行过程与前两种稍微不同:

主线程调用SynchronousQueue的offer()方法放入task,倘若此时线程池中有空闲的线程尝试读取SynchronousQueue的task,即调用了SynchronousQueue的poll(),那么主线程将该task交给空闲线程.否则执行(2)当线程池为空或者没有空闲的线程,则创建新的线程执行任务.执行完任务的线程倘若在60s内仍空闲,则会被终止.因此长时间空闲的CachedThreadPool不会持有任何线程资源.关闭线程池

遍历线程池中的所有线程，然后逐个调用线程的interrupt方法来中断线程.

关闭方式-shutdown

将线程池里的线程状态设置成SHUTDOWN状态,然后中断所有没有正在执行任务的线程.

关闭方式-shutdownNow

将线程池里的线程状态设置成STOP状态,然后停止所有正在执行或暂停任务的线程.只要调用这两个关闭方法中的任意一个,isShutDown()返回true.当所有任务都成功关闭了,isTerminated()返回true.

ThreadPoolExecutor源码详解几个关键属性内部状态

其中AtomicInteger变量ctl的功能非常强大:利用低29位表示线程池中线程数，通过高3位表示线程池的运行状态:

RUNNING:-1<<COUNT_BITS，即高3位为111，该状态的线程池会接收新任务，并处理阻塞队列中的任务；SHUTDOWN:0<<COUNT_BITS，即高3位为000，该状态的线程池不会接收新任务，但会处理阻塞队列中的任务；STOP:1<<COUNT_BITS，即高3位为001，该状态的线程不会接收新任务，也不会处理阻塞队列中的任务，而且会中断正在运行的任务；TIDYING:2<<COUNT_BITS，即高3位为010,所有的任务都已经终止；TERMINATED:3<<COUNT_BITS，即高3位为011,terminated()方法已经执行完成任务的执行

execute–>addWorker–>runworker(getTask)

线程池的工作线程通过Woker类实现，在ReentrantLock锁的保证下，把Woker实例插入到HashSet后，并启动Woker中的线程。从Woker类的构造方法实现可以发现:线程工厂在创建线程thread时，将Woker实例本身this作为参数传入，当执行start方法启动线程thread时，本质是执行了Worker的runWorker方法。firstTask执行完成之后，通过getTask方法从阻塞队列中获取等待的任务，如果队列中没有任务，getTask方法会被阻塞并挂起，不会占用cpu资源；

execute()方法

ThreadPoolExecutor.execute(task)实现了Executor.execute(task)

为什么需要doublecheck线程池的状态?

在多线程环境下，线程池的状态时刻在变化，而ctl.get()是非原子操作，很有可能刚获取了线程池状态后线程池状态就改变了。判断是否将command加入workque是线程池之前的状态。倘若没有doublecheck，万一线程池处于非running状态(在多线程环境下很有可能发生)，那么command永远不会执行。

addWorker方法

从方法execute的实现可以看出:addWorker主要负责创建新的线程并执行任务线程池创建新线程执行任务时，需要获取全局锁:

Worker类的runworker方法继承了AQS类，可以方便的实现工作线程的中止操作；实现了Runnable接口，可以将自身作为一个任务在工作线程中执行；当前提交的任务firstTask作为参数传入Worker的构造方法；

一些属性还有构造方法:

runWorker方法是线程池的核心:

线程启动之后，通过unlock方法释放锁，设置AQS的state为0，表示运行可中断；Worker执行firstTask或从workQueue中获取任务:进行加锁操作，保证thread不被其他线程中断(除非线程池被中断)检查线程池状态，倘若线程池处于中断状态，当前线程将中断。执行beforeExecute执行任务的run方法执行afterExecute方法解锁操作

通过getTask方法从阻塞队列中获取等待的任务，如果队列中没有任务，getTask方法会被阻塞并挂起，不会占用cpu资源；

getTask方法

下面来看一下getTask()方法，这里面涉及到keepAliveTime的使用，从这个方法我们可以看出线程池是怎么让超过corePoolSize的那部分worker销毁的。

注意这里一段代码是keepAliveTime起作用的关键:

allowCoreThreadTimeOut为false，线程即使空闲也不会被销毁；倘若为ture，在keepAliveTime内仍空闲则会被销毁。

如果线程允许空闲等待而不被销毁timed==false，workQueue.take任务:如果阻塞队列为空，当前线程会被挂起等待；当队列中有任务加入时，线程被唤醒，take方法返回任务，并执行；

如果线程不允许无休止空闲timed==true,workQueue.poll任务:如果在keepAliveTime时间内，阻塞队列还是没有任务，则返回null；

任务的提交submit任务，等待线程池execute执行FutureTask类的get方法时，会把主线程封装成WaitNode节点并保存在waiters链表中，并阻塞等待运行结果；FutureTask任务执行完成后，通过UNSAFE设置waiters相应的waitNode为null，并通过LockSupport类unpark方法唤醒主线程；

在实际业务场景中，Future和Callable基本是成对出现的，Callable负责产生结果，Future负责获取结果。

Callable接口类似于Runnable，只是Runnable没有返回值。Callable任务除了返回正常结果之外，如果发生异常，该异常也会被返回，即Future可以拿到异步执行任务各种结果；Future.get方法会导致主线程阻塞，直到Callable任务执行完成；submit方法

AbstractExecutorService.submit()实现了ExecutorService.submit()可以获取执行完的返回值,而ThreadPoolExecutor是AbstractExecutorService.submit()的子类，所以submit方法也是ThreadPoolExecutor`的方法。

通过submit方法提交的Callable任务会被封装成了一个FutureTask对象。通过Executor.execute方法提交FutureTask到线程池中等待被执行，最终执行的是FutureTask的run方法；

FutureTask对象

publicclassFutureTask<V>implementsRunnableFuture<V>可以将FutureTask提交至线程池中等待被执行(通过FutureTask的run方法来执行)

内部状态

内部状态的修改通过sun.misc.Unsafe修改

get方法

内部通过awaitDone方法对主线程进行阻塞，具体实现如下:

如果主线程被中断，则抛出中断异常；

判断FutureTask当前的state，如果大于COMPLETING，说明任务已经执行完成，则直接返回；如果当前state等于COMPLETING，说明任务已经执行完，这时主线程只需通过yield方法让出cpu资源，等待state变成NORMAL；通过WaitNode类封装当前线程，并通过UNSAFE添加到waiters链表；最终通过LockSupport的park或parkNanos挂起线程；

run方法

FutureTask.run方法是在线程池中被执行的，而非主线程

通过执行Callable任务的call方法；如果call执行成功，则通过set方法保存结果；如果call执行有异常，则通过setException保存异常；任务的关闭

shutdown方法会将线程池的状态设置为SHUTDOWN,线程池进入这个状态后,就拒绝再接受任务,然后会将剩余的任务全部执行完

shutdownNow做的比较绝，它先将线程池状态设置为STOP，然后拒绝所有提交的任务。最后中断左右正在运行中的worker,然后清空任务队列。

更深入理解

为什么线程池不允许使用Executors去创建?推荐方式是什么?

线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。说明：Executors各个方法的弊端：

newFixedThreadPool和newSingleThreadExecutor:??主要问题是堆积的请求处理队列可能会耗费非常大的内存，甚至OOM。newCachedThreadPool和newScheduledThreadPool:??主要问题是线程数最大数是Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至OOM。推荐方式1

首先引入：commons-lang3包

推荐方式2

首先引入：com.google.guava包

推荐方式3

spring配置线程池方式：自定义线程工厂bean需要实现ThreadFactory，可参考该接口的其它默认实现类，使用方式直接注入bean调用execute(Runnabletask)方法即可

配置线程池需要考虑因素

从任务的优先级，任务的执行时间长短，任务的性质(CPU密集/IO密集)，任务的依赖关系这四个角度来分析。并且近可能地使用有界的工作队列。

性质不同的任务可用使用不同规模的线程池分开处理:

CPU密集型:尽可能少的线程，Ncpu+1IO密集型:尽可能多的线程,Ncpu*2，比如数据库连接池混合型:CPU密集型的任务与IO密集型任务的执行时间差别较小，拆分为两个线程池；否则没有必要拆分。监控线程池的状态

可以使用ThreadPoolExecutor以下方法:

getTaskCount()Returnstheapproximatetotalnumberoftasksthathaveeverbeenscheduledforexecution.getCompletedTaskCount()Returnstheapproximatetotalnumberoftasksthathavecompletedexecution.返回结果少于getTaskCount()。getLargestPoolSize()Returnsthelargestnumberofthreadsthathaveeversimultaneouslybeeninthepool.返回结果小于等于maximumPoolSizegetPoolSize()Returnsthecurrentnumberofthreadsinthepool.getActiveCount()Returnstheapproximatenumberofthreadsthatareactivelyexecutingtasks.参考文章《Java并发编程艺术》https://www.jianshu.com/p/87bff5cc8d8chttps://blog.csdn.net/programmer_at/article/details/79799267https://blog.csdn.net/u013332124/article/details/79587436https://www.journaldev.com/1069/threadpoolexecutor-java-thread-pool-example-executorservice

由于问答代码块插入受限，部分代码未完全展示，若有需要可阅读原文：戳我阅读原文

c++线程普通变量怎么添加线程

在C++中添加线程操作可以通过创建一个线程函数来实现，线程函数内部可以访问普通变量并进行相关的操作。通过使用std::thread库函数或者pthread_create函数可以创建线程。创建线程时需要传入线程函数，同时也可以传入参数以便线程函数获取相关的输入数据。

在线程函数中可以使用普通变量来进行计算、修改或者读取操作，并使用互斥锁进行线程安全的控制。

线程结束后需要进行资源清理，例如调用pthread_join函数等待线程结束。

C++如何使用thread类多线程编程

大C++程序员可享受原生的多线程机制！浅析C++11多线程内存模型

前言

在C++11标准中，一个重大的更新就是引入了C++多线程内存模型。本文的主要目的在于介绍C++多线程内存模型涉及到的一些原理和概念，以帮助大家理解C++多线程内存模型的作用和意义。(更多C/C++学习资料，请私信我“代码”，即可获取.)

顺序一致性模型（SEQUENTIALCONSISTENCY）

在介绍C++多线程模型之前，让我们先介绍一下最基本的顺序一致性模型。对多线程程序来说，最直观，最容易被理解的执行方式就是顺序一致性模型。顺序一致性的提出者Lamport给出的定义是：

“…theresultofanyexecutionisthesameasiftheoperationsofalltheprocessorswereexecutedinsomesequentialorder,andtheoperationsofeachindividualprocessorappearinthissequenceintheorderspecifiedbyitsprogram.”

从这个定义中我们可以看出，顺序一致性主要约定了两件事情：

（1）从单个线程的角度来看，每个线程内部的指令都是按照程序规定的顺序（programorder）来执行的；

（2）从整个多线程程序的角度来看，整个多线程程序的执行顺序是按照某种交错顺序来执行的，且是全局一致的；

下面我们通过一个例子来理解顺序一致性。假设我们有两个线程（线程1和线程2），它们分别运行在两个CPU核上，有两个初始值为0的全局共享变量x和y，两个线程分别执行下面两条指令：

初始条件：x=y=0;

因为多线程程序交错执行的顺序是不确定的，所以该程序可能有如下几种执行顺序：

顺序一致性模型的第一个约定要求每个线程内部的语句都是按照程序规定的顺序执行，例如，线程1里面的两条语句在该线程中一定是x=1先执行，r1=y后执行。顺序一致性的第二个约定要求多线程程序按照某种顺序执行，且所有线程看见的整体执行顺序必须一致，即该多线程程序可以按照顺序1、顺序2或者顺序3（以及其他可能的执行顺序）执行，且线程1和线程2所观察到的整个程序的执行顺序是一致的（例如，如果线程1“看见”整个程序的执行顺序是顺序1，那么线程2“看见”的整个程序的执行顺序也必须是顺序1，而不能是顺序2或者顺序3）。依照顺序一致性模型，虽然这个程序还可能按其他的交错顺序执行，但是r1和r2的值却只可能出现上面三种结果，而不可能出现r1和r2同时为0的情况。

然而，尽管顺序一致性模型非常易于理解，但是它却对CPU和编译器的性能优化做出了很大的限制，所以常见的多核CPU和编译器大都没有实现顺序一致性模型。例如，编译器可能会为了隐藏一部分读操作的延迟而做如下优化，把线程1中对y的读操作（即r1=y）调换到x=1之前执行：

初始条件：x=y=0;

在这种情况下，该程序如果按下面的顺序执行就可能就会出现r1和r2都为0这样的违反顺序一致性的结果：

那么为什么编译器会做这样的乱序优化呢？因为读一个在内存中而不是在cache中的共享变量需要较长的时钟周期，所以编译器就“自作聪明”的让读操作先执行，从而隐藏掉一些指令执行的延迟，从而提高程序的性能。实际上，这种优化是串行时代非常普遍的，因为它对单线程程序的语义是没有影响的。但是在进入多核时代后，编译器缺少语言级的内存模型的约束，导致其可能做出违法顺序一致性规定的多线程语义的错误优化。同样的，多核CPU中的写缓冲区（storebuffer）也可能实施乱序优化：它会把要写入内存的值先在缓冲区中缓存起来，以便让该写操作之后的指令先执行，进而出现违反顺序一致性的执行顺序。

因为现有的多核CPU和编译器都没有遵守顺序一致模型，而且C/C++的现有标准中都没有把多线程考虑在内，所以给编写多线程程序带来了一些问题。例如，为了正确地用C++实现Double-CheckedLocking，我们需要使用非常底层的内存栅栏（MemoryBarrier）指令来显式地规定代码的内存顺序性（memoryordering）[5]。然而，这种方案依赖于具体的硬件，因此可移植性很差；而且它过于底层，不方便使用。

C++多线程内存模型

为了更容易的进行多线程编程，程序员希望程序能按照顺序一致性模型执行；但是顺序一致性对性能的损失太大了，CPU和编译器为了提高性能就必须要做优化。为了在易编程性和性能间取得一个平衡，一个新的模型出炉了：sequentialconsistencyfordataracefreeprograms，它就是即将到来的C++1x标准中多线程内存模型的基础。对C++程序员来说，随着C++1x标准的到来，我们终于可以依赖高级语言内建的多线程内存模型来编写正确的、高性能的多线程程序。

C++内存模型可以被看作是C++程序和计算机系统（包括编译器，多核CPU等可能对程序进行乱序优化的软硬件）之间的契约，它规定了多个线程访问同一个内存地址时的语义，以及某个线程对内存地址的更新何时能被其它线程看见。这个模型约定：没有数据竞跑的程序是遵循顺序一致性的。该模型的核心思想就是由程序员用同步原语（例如锁或者C++1x中新引入的atomic类型的共享变量）来保证你程序是没有数据竞跑的，这样CPU和编译器就会保证程序是按程序员所想的那样执行的（即顺序一致性）。换句话说，程序员只需要恰当地使用具有同步语义的指令来标记那些真正需要同步的变量和操作，就相当于告诉CPU和编译器不要对这些标记好的同步操作和变量做违反顺序一致性的优化，而其它未被标记的地方可以做原有的优化。编译器和CPU的大部分优化手段都可以继续实施，只是在同步原语处需要对优化做出相应的限制；而且程序员只需要保证正确地使用同步原语即可，因为它们最终表现出来的执行效果与顺序一致性模型一致。由此，C++多线程内存模型帮助我们在易编程性和性能之间取得了一个平衡。

在C++11标准之前，C++是在建立在单线程语义上的。为了进行多线程编程，C++程序员通过使用诸如Pthreads，WindowsThread等C++语言标准之外的线程库来完成代码设计。以Pthreads为例，它提供了类似pthread_mutex_lock这样的函数来保证对共享变量的互斥访问，以防止数据竞跑。人们不禁会问，Pthreads这样的线程库我用的好好的，干嘛需要C++引入的多线程，这不是多此一举么？其实，以线程库的形式进行多线程编程在绝大多数应用场景下都是没有问题的。然而，线程库的解决方案也有其先天缺陷。第一，如果没有在编程语言中定义内存模型的话，我们就不能清楚的定义到底什么样的编译器/CPU优化是合法的，而程序员也不能确定程序到底会怎么样被优化执行。例如，Pthreads标准中并未对什么是数据竞跑（DataRace）做出精确定义，因此C++编译器可能会进行一些错误优化从而导致数据竞跑[3]。第二，绝大多数情况下线程库能正确的完成任务，而在极少数对性能有更高要求的情况下（尤其是需要利用底层的硬件特性来实现高性能LockFree算法时）需要更精确的内存模型以规定好程序的行为。简而言之，把内存模型集成到编程语言中去是比线程库更好的选择。

C++11中引入的ATOMIC类型C++作为一种高性能的系统语言，其设计目标之一就在于提供足够底层的操作，以满足对高性能的需求。在这个前提之下，C++11除了提供传统的锁、条件变量等同步机制之外，还引入了新的atomic类型。相对于传统的mutex锁来说，atomic类型更底层，具备更好的性能，因此能用于实现诸如LockFree等高性能并行算法。有了atomic类型，C++程序员就不需要像原来一样使用汇编代码来实现高性能的多线程程序了。而且，把atomic类型集成到C++语言中之后，程序员就可以更容易地实现可移植的多线程程序，而不用再依赖那些平台相关的汇编语句或者线程库。

对常见的数据类型，C++11都提供了与之相对应的atomic类型。以bool类型举例，与之相对应的atomic_bool类型具备两个新属性：原子性与顺序性。顾名思义，原子性的意思是说atomic_bool的操作都是不可分割的，原子的；而顺序性则指定了对该变量的操作何时对其他线程可见。在C++11中，为了满足对性能的追求，atomic类型提供了三种顺序属性：sequentialconsistencyordering（即顺序一致性），acquirereleaseordering以及relaxedordering。因为sequentialconsistency是最易理解的模型，所以默认情况下所有atomic类型的操作都会使sequentialconsistency顺序。当然，顺序一致性的性能相对来说比较差，所以程序员还可以使用对顺序性要求稍弱一些的acquirereleaseordering与最弱的relaxedordering。

在下面这个例子中，atomic_bool类型的变量data_ready就被用来实现两个线程间的同步操作。需要注意的是，对data_ready的写操作仍然可以通过直接使用赋值操作符（即“=”）来进行，但是对其的读操作就必须调用load()函数来进行。在默认的情况下，所有atomic类型变量的顺序性都是顺序一致性（即sequentialconsistency）。在这个例子中，因为data_ready的顺序性被规定为顺序一致性，所以线程1中对data_ready的写操作会与线程2中对data_ready的读操作构建起synchronize-with的同步关系，即#2->#3。又因为writer_thread()中的代码顺序规定了#1在#2之前发生，即#1->#2；而且reader_thread中的代码顺序规定了#3->#4，所以就有了#1->#2->#3->#4这样的顺序关系，从而可以保证在#4中读取data的值时，#1已经执行完毕，即#4一定能读到#1写入的值（10）。

相信很多朋友会纳闷，这样的执行顺序不是显然的么？其实不然。如果我们把data_ready的顺序性制定为relaxedordering的话，编译器和CPU就可以自由地做违反顺序一致性的乱序优化，从而导致#1不一定在#2之前被执行，最终导致#4中读到的data的值不为10。

简单的来说，在atomic类型提供的三种顺序属性中，acquirereleaseordering对顺序性的约束程度介于sequentialconsistency（顺序一致性）和relaxedordering之间，因为它不要求全局一致性，但是具有synchronizedwith的关系。Relaxedordering最弱，因为它对顺序性不做任何要求。由此可见，除非非常必要，我们一般不建议使用relaxedordering，因为这不能保证任何顺序性。关于这三种属性更详细的信息大家可以参考[1]。

通过上面的例子我们可以看到，C++1x中的多线程内存模型为了通过atomic类型提供足够的灵活性和性能，最大限度地将底层细节（三种不同的顺序属性）暴露给了程序员。这样的设计原则一方面给程序员提供了实现高性能多线程算法的可能，但却也大大增加了使用上的难度。我个人的建议是，如果常规的mutex锁、条件变量、future信号能满足您的设计需求，那么您完全不需要使用atomic变量。如果您决定使用atomic变量，请尽量使用默认的顺序一致性属性。

总结

本文对C++11标准中新引入的多线程内存模型进行了简要介绍。C++11多线程内存模型的引入使得广大C++程序员可以享受语言原生支持的多线程机制，并为实现高性能多线程算法提供了足够丰富的工具（例如atomic类型）。但是，多线程内存模型本身的复杂性，以及一些底层机制（例如不同的顺序性属性）的引入也给使用C++进行多线程编程带来了不小的复杂度。如何高效、可靠的利用好这些新引入的多线程机制将会成为一个新的挑战。

java线程间如何通信

谢邀！

Object的wait方法、notify方法和notifyAll方法可以实现线程间的通讯，wait方法让当前线程等待，同时释放持有的锁，notify方法可以唤醒一个等待的线程，notifyAll方法可以唤醒所有等待的线程，线程间采用竞争的策略获取执行计划，但是需要注意的是这三个方法需要配合synchronized关键字使用。

希望对你有所帮助！

关于多线程操作共享资源保证原子到此分享完毕，希望能帮助到您。