IOS多线程安全（线程锁）

线程的不安全是由于多线程访问和修改共享资源而引起的不可预测的结果。

创新互联建站网站建设提供从项目策划、软件开发，软件安全维护、网站优化(SEO)、网站分析、效果评估等整套的建站服务，主营业务为成都做网站、成都网站建设，重庆APP开发以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。创新互联建站深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

ios多线程开发中为保证线程的安全常用到的几种锁： NSLock 、 dispatch_semaphore 、 NSCondition 、 NSRecursiveLock 、 @synchronized 。

WEAKSELF typeof(self) __weak weakSelf = self;

NSLock 是OC层封装底层线程操作来实现的一种锁，继承NSLocking协议。不能迭代加锁，如果发生两次lock，而未unlock过，则会产生死锁问题。

以车站购票为例，多个窗口同时售票（同步），每个窗口有人循环购票：

原子操作

原子操作是指不可打断的操作，也就是说线程在执行操作的过程中，不会被操作系统挂起，而是一定会执行完，

变量属性Property中的原子定义

一般我们定义一个变量@property (nonatomic ,strong)NSLock *lock;nonatomic：非原子性，不会为setter方法加锁，适合内存小的移动设备；atomic：原子性，默认为setter方法加锁（默认就是atomic），线程安全。

PS： 在iOS开发过程中，一般都将属性声明为nonatomic，尽量避免多线程抢夺同一资源，尽量将加锁等资源抢夺业务交给服务器。

NSCondition常用于生产者-消费者模式，它继承了NSLocking协议，同样有lock和unlock方法。条件变量有点像信号量，提供了线程阻塞和信号机制，因此可以用来阻塞某个线程，并等待数据就绪再唤醒程序。

信号量主要有3个函数，分别是：

注意： 正常的使用顺序是先降低然后提高，这两个函数通常都是成对出现。

本文主要参考了这篇文章(

)，并对其中所能理解的部分进行一一验证，以前没怎么写过类似的，如果有什么做的不好的地方还请大家多多见谅！

多线程安全：确保线程安全的几种方法

线程安全问题主要是由于实例变量使用不当而引起的，这里以一个现实的例子来说明。

Import javax.servlet. *;

Import javax.servlet.http. *;

Import java.io. *;

Public class Concurrent Test extends HttpServlet {PrintWriter output;

Public void service (HttpServletRequest request,

HttpServletResponse response) throws ServletException, IOException {String username;

Response.setContentType ("text/html; charset=gb2312");

Username = request.getParameter ("username");

Output = response.getWriter ();

Try {Thread. sleep (5000); //为了突出并发问题，在这设置一个延时

} Catch (Interrupted Exception e){}

output.println("用户名:"+Username+"BR");

}

}

该Servlet中定义了一个实例变量output，在service方法将其赋值为用户的输出。当一个用户访问该Servlet时，程序会正常的运行，但当多个用户并发访问时，就可能会出现其它用户的信息显示在另外一些用户的浏览器上的问题。这是一个严重的问题。为了突出并发问题，便于测试、观察，我们在回显用户信息时执行了一个延时的操作。假设已在web.xml配置文件中注册了该Servlet，现有两个用户a和b同时访问该Servlet（可以启动两个IE浏览器，或者在两台机器上同时访问）,即同时在浏览器中输入：

a： : 8080/servlet/ConcurrentTest? Username=a

b： : 8080/servlet/ConcurrentTest? Username=b

如果用户b比用户a回车的时间稍慢一点，将得到如图2所示的输出：

从图2中可以看到，Web服务器启动了两个线程分别处理来自用户a和用户b的请求，但是在用户a的浏览器上却得到一个空白的屏幕，用户a的信息显示在用户b的浏览器上。该Servlet存在线程不安全问题。下面我们就从分析该实例的内存模型入手,观察不同时刻实例变量output的值来分析使该Servlet线程不安全的原因。

Java的内存模型JMM（Java Memory Model）JMM主要是为了规定了线程和内存之间的一些关系。根据JMM的设计，系统存在一个主内存(Main Memory)，Java中所有实例变量都储存在主存中，对于所有线程都是共享的。每条线程都有自己的工作内存(Working Memory)，工作内存由缓存和堆栈两部分组成，缓存中保存的是主存中变量的拷贝，缓存可能并不总和主存同步，也就是缓存中变量的修改可能没有立刻写到主存中；堆栈中保存的是线程的局部变量，线程之间无法相互直接访问堆栈中的变量。根据JMM，我们可以将论文中所讨论的Servlet实例的内存模型抽象为图3所示的模型。

如何看懂《Linux多线程服务端编程

一：进程和线程

每个进程有自己独立的地址空间。“在同一个进程”还是“不在同一个进程”是系统功能划分的重要决策点。《Erlang程序设计》[ERL]把进程比喻为人：

每个人有自己的记忆（内存），人与人通过谈话（消息传递）来交流，谈话既可以是面谈（同一台服务器），也可以在电话里谈（不同的服务器，有网络通信）。面谈和电话谈的区别在于，面谈可以立即知道对方是否死了（crash,SIGCHLD），而电话谈只能通过周期性的心跳来判断对方是否还活着。

有了这些比喻，设计分布式系统时可以采取“角色扮演”，团队里的几个人各自扮演一个进程，人的角色由进程的代码决定（管登录的、管消息分发的、管买卖的等等）。每个人有自己的记忆，但不知道别人的记忆，要想知道别人的看法，只能通过交谈（暂不考虑共享内存这种IPC）。然后就可以思考：

·容错：万一有人突然死了

·扩容：新人中途加进来

·负载均衡：把甲的活儿挪给乙做

·退休：甲要修复bug，先别派新任务，等他做完手上的事情就把他重启

等等各种场景，十分便利。

线程的特点是共享地址空间，从而可以高效地共享数据。一台机器上的多个进程能高效地共享代码段(操作系统可以映射为同样的物理内存)，但不能共享数据。如果多个进程大量共享内存，等于是把多进程程序当成多线程来写，掩耳盗铃。

“多线程”的价值，我认为是为了更好地发挥多核处理器(multi-cores)的效能。在单核时代，多线程没有多大价值（个人想法：如果要完成的任务是CPU密集型的，那多线程没有优势，甚至因为线程切换的开销，多线程反而更慢；如果要完成的任务既有CPU计算，又有磁盘或网络IO，则使用多线程的好处是，当某个线程因为IO而阻塞时，OS可以调度其他线程执行，虽然效率确实要比任务的顺序执行效率要高，然而，这种类型的任务，可以通过单线程的”non-blocking IO+IO multiplexing”的模型（事件驱动）来提高效率，采用多线程的方式，带来的可能仅仅是编程上的简单而已）。Alan Cox说过：”A computer is a state machine.Threads are for people who can’t program state machines.”（计算机是一台状态机。线程是给那些不能编写状态机程序的人准备的）如果只有一块CPU、一个执行单元，那么确实如Alan Cox所说，按状态机的思路去写程序是最高效的。

二：单线程服务器的常用编程模型

据我了解，在高性能的网络程序中，使用得最为广泛的恐怕要数”non-blocking IO + IO multiplexing”这种模型，即Reactor模式。

在”non-blocking IO + IO multiplexing”这种模型中，程序的基本结构是一个事件循环（event loop），以事件驱动（event-driven）和事件回调的方式实现业务逻辑：

[cpp] view plain copy

//代码仅为示意，没有完整考虑各种情况

while(!done)

{

int timeout_ms = max(1000, getNextTimedCallback());

int retval = poll(fds, nfds, timeout_ms);

if (retval0){

处理错误，回调用户的error handler

}else{

处理到期的timers,回调用户的timer handler

if(retval0){

处理IO事件，回调用户的IO event handler

}

}

}

这里select(2)/poll(2)有伸缩性方面的不足（描述符过多时，效率较低），Linux下可替换为epoll(4)，其他操作系统也有对应的高性能替代品。

Reactor模型的优点很明显，编程不难，效率也不错。不仅可以用于读写socket，连接的建立(connect(2)/accept(2))，甚至DNS解析都可以用非阻塞方式进行，以提高并发度和吞吐量(throughput)，对于IO密集的应用是个不错的选择。lighttpd就是这样，它内部的fdevent结构十分精妙，值得学习。

基于事件驱动的编程模型也有其本质的缺点，它要求事件回调函数必须是非阻塞的。对于涉及网络IO的请求响应式协议，它容易割裂业务逻辑，使其散布于多个回调函数之中，相对不容易理解和维护。

三：多线程服务器的常用编程模型

大概有这么几种：

a：每个请求创建一个线程，使用阻塞式IO操作。在Java 1.4引人NIO之前，这是Java网络编程的推荐做法。可惜伸缩性不佳（请求太多时，操作系统创建不了这许多线程）。

b：使用线程池，同样使用阻塞式IO操作。与第1种相比，这是提高性能的措施。

c：使用non-blocking IO + IO multiplexing。即Java NIO的方式。

d：Leader/Follower等高级模式。

在默认情况下，我会使用第3种，即non-blocking IO + one loop per thread模式来编写多线程C++网络服务程序。

1：one loop per thread

此种模型下，程序里的每个IO线程有一个event loop，用于处理读写和定时事件（无论周期性的还是单次的）。代码框架跟“单线程服务器的常用编程模型”一节中的一样。

libev的作者说：

One loop per thread is usually a good model. Doing this is almost never wrong, some times a better-performance model exists, but it is always a good start.

这种方式的好处是：

a：线程数目基本固定，可以在程序启动的时候设置，不会频繁创建与销毁。

b：可以很方便地在线程间调配负载。

c：IO事件发生的线程是固定的，同一个TCP连接不必考虑事件并发。

Event loop代表了线程的主循环，需要让哪个线程干活，就把timer或IO channel（如TCP连接）注册到哪个线程的loop里即可：对实时性有要求的connection可以单独用一个线程；数据量大的connection可以独占一个线程，并把数据处理任务分摊到另几个计算线程中（用线程池）；其他次要的辅助性connections可以共享一个线程。

比如，在dbproxy中，一个线程用于专门处理客户端发来的管理命令；一个线程用于处理客户端发来的MySQL命令，而与后端数据库通信执行该命令时，是将该任务分配给所有事件线程处理的。

对于non-trivial（有一定规模）的服务端程序，一般会采用non-blocking IO + IO multiplexing，每个connection/acceptor都会注册到某个event loop上，程序里有多个event loop，每个线程至多有一个event loop。

多线程程序对event loop提出了更高的要求，那就是“线程安全”。要允许一个线程往别的线程的loop里塞东西，这个loop必须得是线程安全的。

在dbproxy中，线程向其他线程分发任务，是通过管道和队列实现的。比如主线程accept到连接后，将表示该连接的结构放入队列，并向管道中写入一个字节。计算线程在自己的event loop中注册管道的读事件，一旦有数据可读，就尝试从队列中取任务。

2：线程池

不过，对于没有IO而光有计算任务的线程，使用event loop有点浪费。可以使用一种补充方案，即用blocking queue实现的任务队列：

[cpp] view plain copy

typedef boost::functionvoid()Functor;

BlockingQueueFunctor taskQueue; //线程安全的全局阻塞队列

//计算线程

void workerThread()

{

while (running) //running变量是个全局标志

{

Functor task = taskQueue.take(); //this blocks

task(); //在产品代码中需要考虑异常处理

}

}

// 创建容量（并发数）为N的线程池

int N = num_of_computing_threads;

for (int i = 0; i N; ++i)

{

create_thread(workerThread); //启动线程

}

//向任务队列中追加任务

Foo foo; //Foo有calc()成员函数

boost::functionvoid() task = boost::bind(Foo::calc，foo);

taskQueue.post(task);

除了任务队列，还可以用BlockingQueueT实现数据的生产者消费者队列，即T是数据类型而非函数对象，queue的消费者从中拿到数据进行处理。其实本质上是一样的。

3：总结

总结而言，我推荐的C++多线程服务端编程模式为：one (event) loop per thread + thread pool：

event loop用作IO multiplexing，配合non-blockingIO和定时器；

thread pool用来做计算，具体可以是任务队列或生产者消费者队列。

以这种方式写服务器程序，需要一个优质的基于Reactor模式的网络库来支撑，muduo正是这样的网络库。比如dbproxy使用的是libevent。

程序里具体用几个loop、线程池的大小等参数需要根据应用来设定，基本的原则是“阻抗匹配”（解释见下），使得CPU和IO都能高效地运作。所谓阻抗匹配原则：

如果池中线程在执行任务时，密集计算所占的时间比重为 P (0 P = 1)，而系统一共有 C 个 CPU，为了让这 C 个 CPU 跑满而又不过载，线程池大小的经验公式 T = C/P。（T 是个 hint，考虑到 P 值的估计不是很准确，T 的最佳值可以上下浮动 50%）

以后我再讲这个经验公式是怎么来的，先验证边界条件的正确性。

假设 C = 8，P = 1.0，线程池的任务完全是密集计算，那么T = 8。只要 8 个活动线程就能让 8 个 CPU 饱和，再多也没用，因为 CPU 资源已经耗光了。

假设 C = 8，P = 0.5，线程池的任务有一半是计算，有一半等在 IO 上，那么T = 16。考虑操作系统能灵活合理地调度 sleeping/writing/running 线程，那么大概 16 个“50%繁忙的线程”能让 8 个 CPU 忙个不停。启动更多的线程并不能提高吞吐量，反而因为增加上下文切换的开销而降低性能。

如果 P 0.2，这个公式就不适用了，T 可以取一个固定值，比如 5*C。

另外，公式里的 C 不一定是 CPU 总数，可以是“分配给这项任务的 CPU 数目”，比如在 8 核机器上分出 4 个核来做一项任务，那么 C=4。

四：进程间通信只用TCP

Linux下进程间通信的方式有：匿名管道(pipe)、具名管道(FIFO)、POSIX消息队列、共享内存、信号(signals)，以及Socket。同步原语有互斥器(mutex)、条件变量(condition variable)、读写锁(reader-writer lock)、文件锁(record locking)、信号量(semaphore)等等。

进程间通信我首选Sockets（主要指TCP，我没有用过UDP，也不考虑Unix domain协议）。其好处在于：

可以跨主机，具有伸缩性。反正都是多进程了，如果一台机器的处理能力不够，很自然地就能用多台机器来处理。把进程分散到同一局域网的多台机器上，程序改改host:port配置就能继续用；

TCP sockets和pipe都是操作文件描述符，用来收发字节流，都可以read/write/fcntl/select/poll等。不同的是，TCP是双向的，Linux的pipe是单向的，进程间双向通信还得开两个文件描述符，不方便；而且进程要有父子关系才能用pipe，这些都限制了pipe的使用；

TCP port由一个进程独占，且进程退出时操作系统会自动回收文件描述符。因此即使程序意外退出，也不会给系统留下垃圾，程序重启之后能比较容易地恢复，而不需要重启操作系统（用跨进程的mutex就有这个风险）；而且，port是独占的，可以防止程序重复启动，后面那个进程抢不到port，自然就没法初始化了，避免造成意料之外的结果；

与其他IPC相比，TCP协议的一个天生的好处是“可记录、可重现”。tcpdump和Wireshark是解决两个进程间协议和状态争端的好帮手，也是性能（吞吐量、延迟）分析的利器。我们可以借此编写分布式程序的自动化回归测试。也可以用tcpcopy之类的工具进行压力测试。TCP还能跨语言，服务端和客户端不必使用同一种语言。

分布式系统的软件设计和功能划分一般应该以“进程”为单位。从宏观上看，一个分布式系统是由运行在多台机器上的多个进程组成的，进程之间采用TCP长连接通信。

使用TCP长连接的好处有两点：一是容易定位分布式系统中的服务之间的依赖关系。只要在机器上运行netstat -tpna|grep port就能立刻列出用到某服务的客户端地址（Foreign Address列），然后在客户端的机器上用netstat或lsof命令找出是哪个进程发起的连接。TCP短连接和UDP则不具备这一特性。二是通过接收和发送队列的长度也较容易定位网络或程序故障。在正常运行的时候，netstat打印的Recv-Q和Send-Q都应该接近0，或者在0附近摆动。如果Recv-Q保持不变或持续增加，则通常意味着服务进程的处理速度变慢，可能发生了死锁或阻塞。如果Send-Q保持不变或持续增加，有可能是对方服务器太忙、来不及处理，也有可能是网络中间某个路由器或交换机故障造成丢包，甚至对方服务器掉线，这些因素都可能表现为数据发送不出去。通过持续监控Recv-Q和Send-Q就能及早预警性能或可用性故障。以下是服务端线程阻塞造成Recv-Q和客户端Send-Q激增的例子：

[cpp] view plain copy

$netstat -tn

Proto Recv-Q Send-Q Local Address Foreign

tcp 78393 0 10.0.0.10:2000 10.0.0.10:39748 #服务端连接

tcp 0 132608 10.0.0.10:39748 10.0.0.10:2000 #客户端连接

tcp 0 52 10.0.0.10:22 10.0.0.4:55572

五：多线程服务器的适用场合

如果要在一台多核机器上提供一种服务或执行一个任务，可用的模式有：

a：运行一个单线程的进程；

b：运行一个多线程的进程；

c：运行多个单线程的进程；

d：运行多个多线程的进程；

考虑这样的场景：如果使用速率为50MB/s的数据压缩库，进程创建销毁的开销是800微秒，线程创建销毁的开销是50微秒。如何执行压缩任务？

如果要偶尔压缩1GB的文本文件，预计运行时间是20s，那么起一个进程去做是合理的，因为进程启动和销毁的开销远远小于实际任务的耗时。

如果要经常压缩500kB的文本数据，预计运行时间是10ms，那么每次都起进程 似乎有点浪费了，可以每次单独起一个线程去做。

如果要频繁压缩10kB的文本数据，预计运行时间是200微秒，那么每次起线程似 乎也很浪费，不如直接在当前线程搞定。也可以用一个线程池，每次把压缩任务交给线程池，避免阻塞当前线程（特别要避免阻塞IO线程）。

由此可见，多线程并不是万灵丹(silver bullet)。

1：必须使用单线程的场合

据我所知，有两种场合必须使用单线程：

a：程序可能会fork(2)；

实际编程中，应该保证只有单线程程序能进行fork(2)。多线程程序不是不能调用fork(2)，而是这么做会遇到很多麻烦：

fork一般不能在多线程程序中调用，因为Linux的fork只克隆当前线程的thread of control，不可隆其他线程。fork之后，除了当前线程之外，其他线程都消失了。

这就造成一种危险的局面。其他线程可能正好处于临界区之内，持有了某个锁，而它突然死亡，再也没有机会去解锁了。此时如果子进程试图再对同一个mutex加锁，就会立即死锁。因此，fork之后，子进程就相当于处于signal handler之中（因为不知道调用fork时，父进程中的线程此时正在调用什么函数，这和信号发生时的场景一样），你不能调用线程安全的函数（除非它是可重入的），而只能调用异步信号安全的函数。比如，fork之后，子进程不能调用：

malloc，因为malloc在访问全局状态时几乎肯定会加锁；

任何可能分配或释放内存的函数，比如snprintf；

任何Pthreads函数；

printf系列函数，因为其他线程可能恰好持有stdout/stderr的锁；

除了man 7 signal中明确列出的信号安全函数之外的任何函数。

因此，多线程中调用fork，唯一安全的做法是fork之后，立即调用exec执行另一个程序，彻底隔断子进程与父进程的联系。

在多线程环境中调用fork，产生子进程后。子进程内部只存在一个线程，也就是父进程中调用fork的线程的副本。

使用fork创建子进程时，子进程通过继承整个地址空间的副本，也从父进程那里继承了所有互斥量、读写锁和条件变量的状态。如果父进程中的某个线程占有锁，则子进程同样占有这些锁。问题是子进程并不包含占有锁的线程的副本，所以子进程没有办法知道它占有了哪些锁，并且需要释放哪些锁。

尽管Pthread提供了pthread_atfork函数试图绕过这样的问题，但是这回使得代码变得混乱。因此《Programming With Posix Threads》一书的作者说：”Avoid using fork in threaded code except where the child process will immediately exec a new program.”。

b：限制程序的CPU占用率；

这个很容易理解，比如在一个8核的服务器上，一个单线程程序即便发生busy-wait，占满1个core，其CPU使用率也只有12.5%，在这种最坏的情况下，系统还是有87.5%的计算资源可供其他服务进程使用。

因此对于一些辅助性的程序，如果它必须和主要服务进程运行在同一台机器的话，那么做成单线程的能避免过分抢夺系统的计算资源。

如何创建线程？如何保证线程安全？

线程安全等级

之前的博客中已有所提及“线程安全”问题，一般我们常说某某类是线程安全的，某某是非线程安全的。其实线程安全并不是一个“非黑即白”单项选择题。按照“线程安全”的安全程度由强到弱来排序，我们可以将java语言中各种操作共享的数据分为以下5类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。

1、不可变

在java语言中，不可变的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再采取任何的线程安全保障措施。如final关键字修饰的数据不可修改，可靠性最高。

2、绝对线程安全

绝对的线程安全完全满足Brian GoetZ给出的线程安全的定义，这个定义其实是很严格的，一个类要达到“不管运行时环境如何，调用者都不需要任何额外的同步措施”通常需要付出很大的代价。

3、相对线程安全

相对线程安全就是我们通常意义上所讲的一个类是“线程安全”的。

它需要保证对这个对象单独的操作是线程安全的，我们在调用的时候不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。

在java语言中，大部分的线程安全类都属于相对线程安全的，例如Vector、HashTable、Collections的synchronizedCollection（）方法保证的集合。

4、线程兼容

线程兼容就是我们通常意义上所讲的一个类不是线程安全的。

线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境下可以安全地使用。Java API中大部分的类都是属于线程兼容的。如与前面的Vector和HashTable相对应的集合类ArrayList和HashMap等。

5、线程对立

线程对立是指无论调用端是否采取了同步错误，都无法在多线程环境中并发使用的代码。由于java语言天生就具有多线程特性，线程对立这种排斥多线程的代码是很少出现的。

一个线程对立的例子是Thread类的supend()和resume()方法。如果有两个线程同时持有一个线程对象，一个尝试去中断线程，另一个尝试去恢复线程，如果并发进行的话，无论调用时是否进行了同步，目标线程都有死锁风险。正因此如此，这两个方法已经被废弃啦。

二、线程安全的实现方法

保证线程安全以是否需要同步手段分类，分为同步方案和无需同步方案。

1、互斥同步

互斥同步是最常见的一种并发正确性保障手段。同步是指在多线程并发访问共享数据时，保证共享数据在同一时刻只被一个线程使用（同一时刻，只有一个线程在操作共享数据）。而互斥是实现同步的一种手段，临界区、互斥量和信号量都是主要的互斥实现方式。因此，在这4个字里面，互斥是因，同步是果；互斥是方法，同步是目的。

在java中，最基本的互斥同步手段就是synchronized关键字，synchronized关键字编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码质量，这两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象。

此外，ReentrantLock也是通过互斥来实现同步。在基本用法上，ReentrantLock与synchronized很相似，他们都具备一样的线程重入特性。

互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也成为阻塞同步。从处理问题的方式上说，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确地同步措施（例如加锁），那就肯定会出现问题，无论共享数据是否真的会出现竞争，它都要进行加锁。

2、非阻塞同步

随着硬件指令集的发展，出现了基于冲突检测的乐观并发策略，通俗地说，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采用其他的补偿措施。（最常见的补偿错误就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步。

非阻塞的实现CAS（compareandswap）：CAS指令需要有3个操作数，分别是内存地址（在java中理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和新值（用B表示）。CAS指令执行时，CAS指令指令时，当且仅当V处的值符合旧预期值A时，处理器用B更新V处的值，否则它就不执行更新，但是无论是否更新了V处的值，都会返回V的旧值，上述的处理过程是一个原子操作。

CAS缺点：

ABA问题：因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。

ABA问题的解决思路就是使用版本号。在变量前面追加版本号，每次变量更新的时候把版本号加一，那么A-B-A就变成了1A-2B-3C。JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

3、无需同步方案

要保证线程安全，并不是一定就要进行同步，两者没有因果关系。同步只是保证共享数据争用时的正确性的手段，如果一个方法本来就不涉及共享数据，那它自然就无需任何同步操作去保证正确性，因此会有一些代码天生就是线程安全的。

1）可重入代码

可重入代码（ReentrantCode）也称为纯代码（Pure Code），可以在代码执行的任何时刻中断它，转而去执行另外一段代码，而在控制权返回后，原来的程序不会出现任何错误。所有的可重入代码都是线程安全的，但是并非所有的线程安全的代码都是可重入的。

可重入代码的特点是不依赖存储在堆上的数据和公用的系统资源、用到的状态量都是由参数中传入、不调用 非可重入的方法等。

（类比：synchronized拥有锁重入的功能，也就是在使用synchronized时，当一个线程得到一个对象锁后，再次请求此对象锁时时可以再次得到该对象的锁）

2）线程本地存储

如果一段代码中所需的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行？如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内。这样无需同步也能保证线程之间不出现数据的争用问题。

符合这种特点的应用并不少见，大部分使用消费队列的架构模式（如“生产者-消费者”模式）都会将产品的消费过程尽量在一个线程中消费完。其中最重要的一个应用实例就是经典的Web交互模型中的“一个请求对应一个服务器线程（Thread-per-Request）”的处理方式，这种处理方式的广泛应用使得很多Web服务器应用都可以使用线程本地存储来解决线程安全问题。

分享标题：多服务器线程安全 多进程服务器与多线程服务器的区别
本文来源：http://ybzwz.com/article/ddeeeoh.html