推荐华硕天选，
天选以二次元的活力和多元的灵魂，打造出新时代动感出位的科技产品。
搭载新一代AMD 锐龙标压处理器 Ryzen™ 5 4600H/Ryzen™ 7 4800H,
全新图灵架构独显，选配Nvidia Geforce GTX1650Ti，4GB GDDR6显存 /
GTX1660Ti，6GB GDDR6显存 /RTX2060，6GB GDDR6显存
拥有突破性的图形性能，游戏畅玩完全没有问题。正因为是高配比的游戏本，所以玩转各类游戏各种当下的热门游戏，都可以轻松运行，采用144Hz IPS电竞屏幕，高刷新率带来流畅的游戏体验，支持Adaptive-sync技术，消除画面撕裂，可以带来最为沉浸式的游戏新体验
二次元美学设计，线条利落，独属配色。
配备双PCIE m.2接口和一个2.5寸硬盘接口。
冰川散热结构它采用的是冰川散热系统，采用防尘风扇设计，长时间游戏也能保持凉爽。
*产品规格可能会依国家地区而有所变动，我们诚挚的建议您与当地的经销商或零售商确认目前销售产品的规格。
原子操作就是不能被线程调度机制中断的操作。不正确的认识：原子操作不需要进行同步。在Java 中除了 long 和 double 之外的所有基本类型的读和赋值，都是原子性操作。而64位的long 和 double 变量由于会被JVM当作两个分离的32位来进行操作，所以不具有原子性，会产生字撕裂问题。但是当你定义long或double变量时，如果使用 volatile关键字，就会获到（简单的赋值与返回操作的）原子性（注意，在Java SE5之前，volatile一直不能正确的工作）。见第四版《Thinking in java》第21章并发。
volatile关键字确保了应用中的可视性。如果你将一个域声明为volatile，那么只要这个域产生了写操作，那么所有的读操作就都可以看到这个修改。
下面来看看volatile 和原子性的区别和联系。我将从下面几个问题进行思考和探索。
第1个问题：如何证明 作者上面所说的long 和 double 的简单操作是非原子性的 - 会产生字撕裂问题，而使用volatile 关键字可以保证 long 或 double 的简单操作具有原子性，以及验证其它的基本类型（如int）的简单操作具有原子性。
思路：
1. 多个任务对同一个 long 变量进行赋值修改，所赋的值为从 1 到64位 仅有1位为1，其余位均为0的数，并所返回赋值完成后的值。如果long 变量不具有原子性，那么很有可能得到一个多个位为1的数或者所有位为0的数，一旦发生，我们输出一条信息，并终止程序。
2. 如果1出现字撕裂，那么long 变量加上 volatile 限制后，赋值返回的数应该都满足从 1 到64位 仅有1位为1，其余位均为0，即不会出现字撕裂。
3. 同理，测试int变量，但是由于int 赋值具有原子性，所以即使不加 volatile 限制，赋值返回的数应该都满足从 1 到64位 仅有1位为1，其余位均为0。
具体见下面我写的测试代码
// 证明 long 变量简单操作（赋值和返回）不具有原子性，存在字撕裂问题。验证 volatile 可确保
// long 变量简单操作具有原子性。验证 int 变量简单操作（赋值和返回）具有原子性
package concurrency
import java.util.concurrent.*
class Operation{
private int num = 0
private long bigNum = 0
public int assignInt(int n){
num = n
Thread.yield()
return num
}
public long assignLong(long n){
bigNum = n
Thread.yield()
return bigNum
}
}
public class AtomicTest{
static class IntOperationTask implements Runnable{
private Operation operation
public IntOperationTask(Operation op){
operation = op
}
public void run() {
while(true){
int oldNum, newNum
for(int i = 0i <32i++){
oldNum = 1 <<i
newNum = operation.assignInt(oldNum)
if(oldNum != newNum){
int bits = 0
for(int j = 0j <32j++){
if(0 != (newNum &(1 <<j)))
bits++
}
if(1 != bits){
System.out.printf("[int TEST] It is no atomic operation." +
" old:x new:xn",oldNum, newNum)
System.exit(0)
}
//else
//System.out.printf("[int TEST] It is no synchronousoperation." +
//" old:x new:xn",oldNum, newNum)
}
}
}
}
}
static class LongOperationTask implements Runnable{
private Operation operation
public LongOperationTask(Operation op){
operation = op
}
public void run() {
while(true){
long oldNum, newNum
long one = 1
for(int i = 0i <64i++){
oldNum = one <<i
newNum = operation.assignLong(oldNum)
if(oldNum != newNum){
int bits = 0
for(int j = 0j <64j++){
if(0 != (newNum &(one <<j)))
bits++
}
if(1 != bits){
System.out.printf("[long TEST] It is no atomic operation. " +
"old:6x new:6xn",oldNum, newNum)
System.exit(0)
}
}
}
}
}
}
public static void main(String[] args){
Operation op = new Operation()
ExecutorService service = Executors.newCachedThreadPool()
for(int i = 0i <10i++){
//service.execute(new IntOperationTask(op))
service.execute(new LongOperationTask(op))
}
}
}
测试结果:
1. 当long 没有使用 volatile 修饰时，不到几秒，就出现了字撕裂：
[long TEST] It is no atomic operation. old:0000010000000000 new:0000002000000001
[long TEST] It is no atomic operation. old:0000000000040000 new:0000000000000000
[long TEST] It is no atomic operation. old:0000000080000000 new:0000000000000000
[long TEST] It is no atomic operation. old:0000000000100000 new:0000000000000000
[long TEST] It is no atomic operation. old:0010000000000000 new:0000000000000000
[long TEST] It is no atomic operation. old:0000000000000001 new:0000002000000001
[long TEST] It is no atomic operation. old:0001000000000000 new:0000000000000000
[long TEST] It is no atomic operation. old:0001000000000000 new:0000000000000000
[long TEST] It is no atomic operation. old:0000000010000000 new:0000000180000000
上面的测试是在公司的电脑上进行的，可是回到家里我使用我自己的笔记本电脑进行测试了1分钟，都没有出现字撕裂！这是怎么回事？它吊起了我的兴趣！两台都 是Win7 64位电脑，都是多核Intel CPU，CPU型号不一样，使用的JRE不一样，一个是JRE6（出现字撕裂），一个是JRE7（运行1分钟仍未出现字撕裂）。我怀疑是JRE问题，把这 台电脑的Eclipse 运行环境换成JRE6，还是没有出现！难道和CPU有关系，这可不好搞，我心里嘀咕着。冷静下来，再分析了下，看了下JRE6的路径是 "C:Program FilesJavajre6" ，我这是Win7 64系统，这意味着我使用的是64位jre环境，会不会我公司用的是32位jre环境？我立即把Eclisep 运行环境换成32位的 jre: "C:Program Files (x86)Javajre6"，果然一运行，就出现字撕裂，这次只打印了一条，见下面的打印信息。可以观察到，当使用32位的jre运行 时，javaw.exe 进程是32位进程，但使用64位jre运行时，javaw.exe 进程是64位进程，所以很有可能在64位的jre环境，long double 64位不需要再分离成两个32位来进行操作，即很有可能它们的赋值操作也是原子性的。
[long TEST] It is no atomic operation. old:4000000000000000 new:0000000000000000
2. 而当long变量使用 volatile 修饰后，程序运行了几分钟，也未出现上面的情况。
3. int 变量未使用 volatile 修饰，也未出现字撕裂情况。
第2个问题：作者说在java 中 ++ 操作是非原子性操作，那如果使用++递增一个volatile 的int变量，会发生说明，也就是对一个volatile 的变量进行非原子性操作会发生什么，会不会像volatile 限定 long double 变量那样，使得 ++ 变为一个原子性操作呢？
这个问题《Thinking in java》的作者已给出解答和验证代码。当多个任务异步调用 nextSerialNumber 会出现什么问题呢？
//: concurrency/SerialNumberGenerator.java
package concurrency
public class SerialNumberGenerator {
private static volatile int serialNumber = 0
public static int nextSerialNumber() {
return serialNumber++// Not thread-safe
}
} ///:~
思考：
如果 ++ 是原子性操作，那么由于serialNumber 加上了 volatile 限定，所以任何线程对 serialNumber 的修改，在其它线程都可以看到这个修改。并且 return 一个 int 也是原子操作，即不会中断，所以s如果 ++ 是原子性操作，那么serialNumber在内存的值变化一定是递增的（在int 还未溢出为负数时），注意这里并没有说返回的值一定是递增的，因为可能在++ 完成后，任务就被中断，其它任务继续递增了nextSerialNumber 的值，并返回该值，然后之前那个任务才继续返回，这样返回的值就不是递增的了，但是返回的值在一定的区间内肯定是不会出现重复的（在int 还未循环回0时）。
如果 ++ 是非原子性操作，那么有可能有某个任务已经读取 serialNumber到寄存器了，并在在执行++操作时发生中断（这个时候serialNumber值还未完成加1，如果是具有则原子性则不会被中 断），此时另外一个任务也把serialNumber读取到寄存器，并执行完++操作后（虽然具有volatile 的限定，但是前面一个任务已经在此之前读取了serialNumber，所以也就看不到现在serialNumber修改后的值），前面那个任务才继续执 行++操作，那么这两个任务实际上只对serialNumber完成加1的操作，而不是加2的操作，也就是说这两次调用返回的值是一样的！
通过上面的分析，我们可以断定，如果++具有原子性，返回的值在一定的区间内不会发生重复，否则可能会发生重复。
下面是 《Thinking in java 》作者写的代码
//: concurrency/SerialNumberChecker.java
// Operations that may seem safe are not,
// when threads are present.
// {Args: 4}
package concurrency
import java.util.concurrent.*
// Reuses storage so we don't run out of memory:
class CircularSet {
private int[] array
private int len
private int index = 0
public CircularSet(int size) {
array = new int[size]
len = size
// Initialize to a value not produced
// by the SerialNumberGenerator:
for(int i = 0i <sizei++)
array[i] = -1
}
public synchronized void add(int i) {
array[index] = i
// Wrap index and write over old elements:
index = ++index % len
}
public synchronized boolean contains(int val) {
for(int i = 0i <leni++)
if(array[i] == val) return true
return false
}
}
public class SerialNumberChecker {
private static final int SIZE = 10
private static CircularSet serials =
new CircularSet(1000)
private static ExecutorService exec =
Executors.newCachedThreadPool()
static class SerialChecker implements Runnable {
public void run() {
while(true) {
int serial =
SerialNumberGenerator.nextSerialNumber()
if(serials.contains(serial)) {
System.out.println("Duplicate: " + serial)
System.exit(0)
}
serials.add(serial)
}
}
}
public static void main(String[] args) throws Exception {
for(int i = 0i <SIZEi++)
exec.execute(new SerialChecker())
// Stop after n seconds if there's an argument:
if(args.length >0) {
TimeUnit.SECONDS.sleep(new Integer(args[0]))
System.out.println("No duplicates detected")
System.exit(0)
}
}
} //:~
结论：当你定义long或double变量时，如果使用volatile关键字限定 long 或 double 变量，就会获到（简单的赋值与返回操作的）原子性（注意，在Java SE5之前，volatile一直不能正确的工作），若没有使用volatile关键字限定，那么在32位JRE环境下，肯定是非原子性的，在64位 JRE环境下，很有可能具有原子性（上面我的测试是没有出现字撕裂，呵呵，但我不敢肯定是否一定具有原子性）。但是如果你想使++ 递增操作具有原子性，而仅仅只是同样使用 volatile 进行限定，那么你就会出错！引用《Thinking in java》作者的话：原子操作就是不能被线程调度机制中断的操作。不正确的认识：原子操作不需要进行同步。volatile关键字确保了应用中的可视性。 如果你将一个域声明为volatile，那么只要这个域产生了写操作，那么所有的读操作就都可以看到这个修改。
