67、再谈原子性：Java规范规定所有变量写操作都是原子的

topic，每一周发的课其实都是讲一个完整的topic，在大量的实战过了volatile、Atomic、ThreadLocal、synchronized、读写锁，写了很多的代码，而且对一些基本的原理都有了一定的掌握之后

回过头来，来看看这个java并发技术底层的原理，volatile、synchronized的对可见性、有序性的保障的语义，底层其实是基于内存屏障来实现的，硬件底层原理（高速缓存、写缓冲器、无效队列），各种内存屏障在底层硬件层面他的实现的原理

回过头来看看，volatile和synchronized通过各种内存屏障的使用，底层在硬件级别的实现原理到底是什么

可见性、有序性、原子性，都彻底通透了以后，硬件级别的原理，给大家再说一下CAS底层的硬件级别的原理

同步器，CountDownLatch、Semaphore，诸如此类的一些API，本身其实就是用起来非常简单的，其实就是用来做一些多线程同步的控制，剖析一下里面的源码， 再带着大家在微服务注册中心项目，以及轻量级分布式存储系统案例，做一下实战

并发包下的集合，ConcurrentHashMap，ConcurrentLinkedList，解析里面的源码，带着在各种项目来实战

线程池，底层源码，以及项目里的实战

并发技术的实战、底层源码/原理、纯手工写了微服务注册中心的大部分功能、轻量级的分布式存储系统的案例

跟着这个里面做也行，把微服务注册中心完全工业级的各种功能再完善一下，做成一个完全类似eureka，生产可用的微服务注册中心，初步优化他里面的一些问题，他的服务感知的时效性，秒级感知服务上下线，重构自我保护机制（解决里面的bug）

用一个http请求包，把register-client和register-server之间的网络通信给他跑通

尝试在spring cloud里面集成一下我们的这个东西，替换掉原生的eureka

并发课全部结束，第一个中间件项目结束，微服务注册中心

io、网络、netty、zk，讲完了以后，继续升级微服务注册中心的架构，升级架构更加的复杂和完美，网络通信绝对是要基于netty来重构

=======================================================

Applications apps;

线程1：

apps = loadedApps; // 原子的，不需要AtomicReference来处理

java语言规范里面，int i = 0，resource = loadedResoures，flag = true，各种变量的简单的赋值操作，规定都是原子的

包括引用类型的变量的赋值写操作，也是原子的

你赋值的时候，要保证没有人先赋值过，没有人修改过，你才能赋值，AtomicReference的CAS操作来实现了，之前给大家讲解过的

但是很多复杂的一些操作，i++，先读取i的值，再跟新i的值，i = y + 2，先读取y的值，再更新i的值，这种复杂操作，不是简单赋值写，他是有计算的过程在里面的，此时java语言规范默认是不保证原子性的

volatile，保证的可见性和有序性，原子性，杠精，偷换概念，胡说八道；i++，i = y + 2，不是volatile可以保证原子性的