多线程基础总结五－－atomic

核心提示：在简单介绍java.util.concurrent.atomic包之前，有个概念要先抄袭熟悉一遍：CAS(比较并交换)，多线程基础总结五－－atomic，现在大多数的处理器都提供对并发访问的支持，这个支持的反映方式就是提供硬件的指令支持多处理的特殊需求，没有好的64位三方软件的繁荣，操作系统仅仅作为一个支撑软件运行的平

在简单介绍java.util.concurrent.atomic包之前，有个概念要先抄袭熟悉一遍：CAS(比较并交换)。现在大多数的处理器都提供对并发访问的支持，这个支持的反映方式就是提供硬件的指令支持多处理的特殊需求。比如检测或者阻止其它处理器的并发访问来更新共享变量的指令。对于 Intel x86架构的处理器来说就是通过提供实现CAS或者比较并设置的硬件原语指令集。CAS操作的三个操作数：内存位置（V），预期原值（A）和新值（B）。执行的过程通常是：预测内存地址V应该包含值A，如果包含则将值B替换到位置V；否则，不更改任何值，告知地址V的当前值。CAS对待“读－修改－写”的操作一般是检测这个过程是否有其它的线程在修改变量，如果有那么这次的CAS操作失败，可以尝试重新进行CAS。讲到这里似乎感觉比 Synchronized还复杂，是否意味着成本不小呢？答案是否。因为它是硬件原生实现的，极为轻量级的无锁同步方式。就好像高清解码一样，GPU原生硬件解码比软解的CPU占用优势那是相当的不一样啊！

说到硬件我就想到最近狂能争论的使用64位操作系统的优势。现在处理器多数支持64位，意味着处理器的寄存器映射到内存的寻址空间大大的大了，操作系统 64位的架构或许在内存管理上的挑战更大了，没有好的内存压缩技术，大内存只能是大浪费。同时还表示如果三方软件开发者对64位系统内存管理不熟悉，软件变垃圾的概率变大了。没有好的64位三方软件的繁荣，操作系统仅仅作为一个支撑软件运行的平台能干什么呢?所以使用优势不在操作系统本身而在于平台之上的软件。又扯远了，哎...