zhangshenglu1的博客

AQS就是AbstractQueuedSynchronizer抽象类，AQS其实就是JUC包下的一个基类，JUC下的很多内容都是基于AQS实现了部分功能，比如ReentrantLock，ThreadPoolExecutor，阻塞队列，CountDownLatch，Semaphore，CyclicBarrier等等都是基于AQS实现。线程多并发的时候，如果线程抢占不到锁，就会把抢占不到锁的线程包装成一个Node实例，然后放入AQS的双向队列中。一、ReentrantLock的基本使用示例。

如果按照正常顺序来说也不会有问题，但是指令2和指令3之间不存在依赖关系，编译器优化后可能产生重排，执行顺序为1 --> 3 --> 2,那么这个时候可能会产生在A线程刚把instance指向对应地址后，B线程获取到执行权，然后获取到一个没有初始化的对象，从而产生空指针异常。而编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如: a =6;在这个例子里，编译器调整了语句的顺序，但不会影响到最终结果。语句，该语句会执行三个操作，1、开辟空间 2、初始化 3、instance指向地址。

线程切换是带来原子的根本原因，java的并发程序是基于多线程的，自然就会涉及到任务切换。而任务切换的时机是可以发生cpu的时间片结束时，由于目前我们使用的编程语言都是高级语言，一条高级语言往往是需要多条CPU指令完成的，例如count++,至少需要三条CPU指令。如下图所示，两个线程如果在执行count++的时候，过程如果发生了线程切换，会导致得不到预期的结果2，可能会出现意向不到结果，两个线程对count执行++操作后，在主内存中值为1.

如果在main线程中调用了t1.join(2000)，那么main线程会进入到等待状态，需要等待t1执行2s后，在恢复到就绪状态等待CPU调度。wait方法会将持有锁的线程从owner扔到WaitSet集合中，这个操作是在修改ObjectMonitor对象，如果没有持有synchronized锁的话，是无法操作ObjectMonitor对象的。如果在main线程中调用了t1.join()，那么main线程会进入到等待状态，需要等待t1线程全部执行完毕，在恢复到就绪状态等待CPU调度。

BLOCKED、WAITING、TIME_WAITING：都可以理解为是阻塞、等待状态，因为处在这三种状态下，CPU不会调度当前线程。RUNNABLE：Thread对象调用了start方法，就为RUNNABLE状态（CPU调度/没有调度）TIME_WAITING：调用sleep方法或者join方法，会被自动唤醒，无需手动唤醒。WAITING：调用wait方法就会处于WAITING状态，需要被手动唤醒。上对线程状态的描述很多，有5种，6种，7种，都可以接受。Java中给线程准备的6种状态。

启动线程是调用start方法，这样会创建一个新的线程，并执行线程的任务。如果直接调用run方法，这样会让当前线程执行run方法中的业务逻辑。

虽然多线程带来了一定的性能提升，但是再做一些操作时，多线程如果操作临界资源，可能会发生一些数据不一致的安全问题，甚至涉及到锁操作时，会造成死锁问题。不如要处理一个网络等待的操作，开启一个线程去处理需要网络等待的任务，让当前业务线程可以继续往下执行逻辑，效率是可以得到大幅度提升的。进程之间的资源通常是独立的。异步非阻塞这个效果是最好的，平时开发时，提升效率最好的方式就是采用异步非阻塞的方式处理一些多线程的任务。在只有一个桶子的场景的下，10个轮流来，一个个排着队去挑，只有上一个挑完回来下一个才能接着干，