chuige2013的博客

同一进程的线程共享此线程的资源，当一个线程发生崩溃时，此进程也会发生崩溃，稳定性差，容易出现共享与资源竞争产生的各种问题，如死锁等。线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行程序计数器和栈，线程之间切换的开销小。当前线程 CPU 时间片用完后，会让出 CPU 等下次轮到自己时候在执行，系统不会为线程分配内存，线程组之间只能共享所属进程的资源。调用线程的 start() 方法后，线程处于可运行状态，此时它可以由 JVM 调度并执行，这并不意味着线程就会立即运行。

总结起来，很多同学都对AQS有一种云里雾里的感觉，如果用搜索引擎查一下AQS是什么，估计看几篇文章就直接放弃了，因为密密麻麻的文字，实在是看不懂！接着，线程2会将自己放入AQS中的一个等待队列，因为自己尝试加锁失败了，此时就要将自己放入队列中来等待，等待线程1释放锁之后，自己就可以重新尝试加锁了。他释放锁的过程非常的简单，就是将AQS内的state变量的值递减1，如果state值为0，则彻底释放锁，会将“加锁线程”变量也设置为null！接着，如果线程1加锁了之后，线程2跑过来加锁会怎么样呢？

总结：我们不能通过run方法来新开一个线程，只能调用线程中重写的run方法（可以在线程中不断的调用run方法，但是不能开启子线程，即不能同时干几件事），start是开启线程，再调用方法（即默认开启一次线程，调用一次run方法，可以同时执行几件事）操作共享数据的代码（所有线程共享的数据的操作的代码）（视作卫生间区域（所有人共享的厕所）），即为需要共享的代码（同步代码块，在同步代码块中，相当于是一个单线程，效率低）2)问题出现的原因：当某个线程操作车票的过程中，尚未完成操作时，其他线程参与进来，也来操作车票。

我们都知道使用多线程的本质是为了提升程序的性能，总体来说有两个最核心的指标，一个延迟，一个吞吐量。延迟指的是发出请求到收到响应的时间，吞吐量指的是。这两个指标之间有一定的关联，因为同等条件下延迟越短吞吐量越大，但由于它们是不同的维度，一个是时间，一个是空间，并不能相互转换。>那么第1种情况，对于CPU密集型任务而言，理论上“线程的数量 = CPU核数”就是合适的。有位工作5年的小伙伴问我说，为什么Netty线程池默认大小为CPU核数的2倍，今天，我花2分钟时间给大家专门分享一下我对这个问题的理解。

而当wait()释放锁后，notifyThread线程会由阻塞状态尝试竞争锁，并拿到锁，开始执行同步块，当执行到notify()方法后，会将waitThread线程从等待队列中移到同步队列中，即notify方法会触发waitThread线程由WAITING非竞争状态转化为BLOCKED状态；从上面叙述可以看出，不管是notifyThread竞争锁，还是notify之后，waitThread需要重新进入同步队列，重新竞争锁，，最后都需要在阻塞状态下竞争同一个锁对象，，因此，等待/通知机制仍依托于同步机制。