都是中文译版

/**
 * Creates an {@code ArrayBlockingQueue} with the given (fixed)
 * capacity and the specified access policy.
 *
 * @param capacity the capacity of this queue
 * @param fair if {@code true} then queue accesses for threads blocked
 *        on insertion or removal, are processed in FIFO order;
 *        if {@code false} the access order is unspecified.
 * @throws IllegalArgumentException if {@code capacity < 1}
 */
public ArrayBlockingQueue(int capacity, boolean fair) {
    if (capacity <= 0)
        throw new IllegalArgumentException();
    this.items = new Object[capacity];
    lock = new ReentrantLock(fair);
    notEmpty = lock.newCondition();
    notFull =  lock.newCondition();
}

构造方法里面初始化了lock对象

System.out.println("Hello World");

解释：当线程1将piao()方法调入栈中执行时，线程2也将piao()方法调入栈中执行，但是由于piao()方法被锁所以线程2处于等待，然而此时线程2已经读取了内存中的 x 的值，所以当线程1执行完成虽然修改了 x 的值，但是由于线程2已经读取了 x 的值，所以修改后的 x 的值并没有被线程2读取。

注意：1、可以给x添加volatile修饰符，这样线程就能读取正确的值

          2、一般情况下对于并发共享的类最好不要拥有状态，容易出现并发问题

wait()方法是让线程释放对象锁，让其他线程拿到锁之后去优先执行，当其他全程唤醒wait()中的线程 或者 拿到对象锁的线程都执行完释放了对象锁之后，wait()中的线程才会再次拿到对象锁从而执行。

百度找找  有扫描版本的

三个方法里至少有一个是notifyAll。假设三个都是notify()，当方法c运行完后，flag为1,此时如果a和b都已经在Wait Set中，且随机唤醒的是b，那么b随机又进入Wait set，c也进入Wait set，此时三个线程全部进入Wait set，造成了死锁。

代码1：两个线程同时走，他俩公用一个FlagSender对象里面的flag，当线程t1走第一遍时，flag等于false，不等待直接输出，然后将falg致成true，线程t1等待，这时候线程t2 while里面的!f.isFlag() 为false，所以往下进行输出又将flag致成false，这时线程t1又开始执行。以此类推。

代码2：两个对象都在while里面进行死循环，所以只打印一次。

你的print2方法里，wait方法没有在if分支里。

课程下面的的资料下载

当年我学也没有，推荐一种写法

private boolean flag=true;

public void setFlag(boolean f ){

flag=f;

}

在别的地方调用setFlag来改变标志。

老师讲的关键字是什么时候出的我都不知道，我手边的书附录java关键字表也没有它

我推荐的书都有中文版的。

首先这是个很棒的问题。这个问题本身其实超出了多线程的讨论范围，因为你考虑的场景是用集群服务器来工作，多线程的讨论范围应该是在一个物理CPU内。但是这真的是一个很好的问题，我很想尝试回答一下。

需要声明的是我的回答是我个人的思考，不代表什么正确答案之类的东西，仅供你参考。

一个集群需要互斥的访问共享资源，那么集群间是需要通信的，通信有一个中心节点我们称之为Master, 真正负责处理业务逻辑的节点我们称之为Slave。通常Master将资源指定给某一个Slave来处理，选取特定Slave需要使用投票算法。热的烫手的Hadoop就是这样一种模式。但仅仅是这样我觉得还不足以回答你得疑问，我们如何保证资源被正确的分配？比如10本书本正确分配给是个订单（假设每单买一本），剩余数量是0时不会继续销售。首先看电商的处理方式，他们其实降低了难度，因为并不是实时销售的，你在电商购物时会注意到提交订单后会受到邮件说订单成功受收到，正在受理。后续他们会审批的啊，审批通过了才邮件告诉你订单受理成功正在出库。

基于以上，我想你感兴趣的是另外一种场景，12306有没有？12306是实时销售的例子，这种场景解决方案一种是将真正减库存的地方串行化处理，如果你得峰值压力不是特大，这应该没问题，不就相当于单线程嘛。另一种方案是加锁，在数据库表的行上加锁，可以是数据库提供的锁，也可以是业务模拟的锁（比如一个叫lock的表，插入一行记录标示摸个资源被锁定了）。需要说明的是直接用数据库提供的锁是有风险的，要吗性能降低的什么迅猛，要么搞成死锁，要再严重把数据库搞坏了就不好了。我真的听说过某省的烟草局项目因为数据库的锁把整个生产环境搞得无法恢复的案例。

好了个人观点，希望能到你。