测试小花花重口味java多线程，慎入。。。。。

下面内容，参考《Java高并发程序设计》书籍。

写在前面：能不用多线程就不用多线程，我们的分布式架构，已经是物理多线程了。

Tip1：并发与并行：

并发是存在临界区竞争的，宏观上同时，微观上有先后，所以，才有锁的概念。去东莞，进了屋，要上锁。完事了，出门释放锁，下一个哥们再来。

艹，本来要写一篇正经的，又下道儿了。。。。。。

并行是两条平行线，比如多核CPU就是并行的，单核的就不行，一次cpu只能执行一个命令，所谓一心不能二用。

Tip2：死锁，活锁

死锁：哥在厕所玩手机，心想没人敲门我就不出来，门外KK很有礼貌，门不开，就不进去。然后我俩就相互等待，最后我得了痔疮，KK拉了裤裆.......

活锁：哥和DD一起去厕所，发现就一个坑，我说你先来，他说你先来，我说你先来，他说你先来，我说你先来，他说你先来...... 最后我们都拉了裤裆

Tip3：并发控制策略

阻塞：大号一般都有锁，完事儿了，开门解锁，下一个继续，门外等的一般都拿起手机，被挂起。

无饥饿：无论多牛逼，优先级多高的人物，没有特殊通道，必须乖乖排队，这样所有的人都可以去厕所，没有人饿着。小米抢手机....

无阻碍：到斯卡拉小包间儿不锁门，YY推门一进来，老妹儿就说，大哥旁边看一会儿，现在都在忙呀。YY急的不行，隔会儿就问快点儿，好没，好没。。。。等同于乐观锁。

无等待：哥们去买上好的玉镯，只有一对儿，好几个买主。这时店主很聪明，做了一堆仿品，让我们几个先看着，最终哪个确认买了，在给谁真的进行交易。等同于RCU锁，适用于读多写少。

Tip4：要不要多线程

amdahl定律：加速比= 优化前系统耗时/优化后系统耗时
如果系统中没有能可被并行化的代码，这多线程毫无意义

Tip5：JavaMM的根本特性

原子性：两个线程互相不会干扰对方的操作，如A线程int i = 1 B线程int i= -1 ，那么无论如何执行，i 要么是1 要么是-1 而32位的long型就不是这样，会出现很多意外的值。

可见性：指令重排会让变量的赋值发生顺序变化，所以，线程之间观测变量是否有保证，是我们设计多线程要考虑的。

有序性：如果不遵循Happen-before原则，比如

class OrderExample
{

int a = 0 ;
boolean flag = false;

public void writer()
{
    a = 1;
    flag = true;
}

public void reader()
{
   if(flag)
      {
init i = a + 1 ;
...
      }
}

}

如果线程A先执行writer()方法，接着线程B执行reader()方法，如果发生指令重排，即
public void writer()
{

flag = true;
a = 1;

}

那reader 的业务逻辑整个往下就全错了.

Tip6：基础的坑坑

1.run和start的区别：run只是执行当前线程的默认run方法，如果没有override的话，啥也不干，而start才是创建新线程，并调用每个线程默认的run方法呀

2.stop的坑在于终止线程的时候，根本不考虑数据一致性，所以，如果你去民政局改名字改到一半，线程stop了，舍普琴科就叫舍瓦了。。。

3.sleep只是傻傻的等待，并跑出中断标记，wait和notify才是可以根据指定的操作对象，进行相互调度，而且wait可以释放锁

4.suspend绝对不能用，挂起了也不释放，如果resume先与其执行，就永远占用着资源了

5.join的本质是让调用线程等待在当前线程的对象实例上，所以就是相亲相爱一起走

6.yield就是弱逼，先检测当前是否有相同优先级的线程处于同可运行状态，如有，则把CPU的占有权交给次线程，否则继续运行原来的线程，所以yield()方法称为“退让”，它把运行机会让给了同等级的其他线程。

7.volatile做不了计数器，仅仅是让变量每次在使用的时候，都从主存中取。

8.线程优先级仅仅是大多数情况下好用，无法精准控制

9.synchronized滥用的情况就一个原理，用在了你以为大家都玩这一个，其实各玩儿各的。如new对象上，Integer上

10.线程不安全的容器使用是多线程的大忌，如arrayList，HashMap，原理都是链表破坏。。

Tip7：JDK并发包

1.ReentrantLock更加灵活，自定义中断响应，等待时长

2.公平锁保证了公平，但付出了管理队列的代价

下面什么信号量，读写锁，线程池，未完待续。。。。。