比如A有20能量，要传30能量给B，不满足，到wait set

但如果之后有别的空间传能量给A，那就可以满足了

编码换成GBK，这几个文件不是UTF-8编码的

异步是进程之间彼此独立，在等待其他进程的运行时，本进程继续做自己的事，不需要等待其他进程完成后再工作。而互斥，是多个并发进程之间，因竞争使用临界资源而互相排斥执行的间接制约关系。

唤醒所有线程，然后重新进行一次判断，不满足的再次进入阻塞

对的，然后等待其他线程调用同一条件变量的notify()或者notifyAll()方法

视频右下方就有个资料下载啊。

能量不守恒 即  energy[from]<amount    说明 没有资源。

需要等待 有可用资源的 时候 才能执行下面的 业务逻辑

synchronize(lockObj) { <------- 这个获取锁操作会增加系统开销
    if（energyBoxs[from]<amount){
        return;
    }
    ...
}

之前的写法：每次成功获取锁之后，先条件判断，若为false，则返回，释放锁。
然后又要再次获取锁，这样操作会以很大的系统开销作为代价的。改成下面写法的话：

synchronize(lockObj) { 
    while（energyBoxs[from]<amount){
        lockObj.wait()；
    }          
}

就是为了减小系统开销

在EnergySystemTest中只创建了一个EnergySystem对象eng，每个线程使用的都是eng这对象里lockObj对象。

你所谓的操作系统指的是啥？多线程在java中算是不太难的知识点了，主要可以通过类比去理解，比如超市，比如买票等，学线程重在理解，难在互斥和同步，不懂了，停下来想一想，或者看一个类似视频，慢慢理解了，就懂了

仔细看下图将能找到答案！

产生能量消亡的原因是，程序中的条件征用，也就会不同线程对同一片内存区域操作的混乱二造成的，现在讲的是如何避免这种条件征用的发生。

return后该线程还会继续和其他线程一起竞争资源，这样无形之间增加了上锁的系统开销，用wait的话直接到wait

set等待唤醒。

当调用了wait方法后，线程是先释放掉了锁才进入了wait set的，当调用notify方法唤醒wait set里的线程后，线程获得cpu资源则会重新去获取锁，重新去判断条件，而不是处在之前没有满足条件的状态。

notifyAll（）；

条件不满足时也就是其它线程还没有将数据写回（这里的lockObj是EnergySystem的final成员，用来标记EnergySystem，lockObj.wait()也就相当于EnergySystem实例.wait()），等待写入之后（也就是满足条件），执行逻辑代码，在唤醒其它线程（有可能还没有写入数据的）。可以回头看争用条件那节,有助于理解，我专门截了图。

抱歉，好久没来慕课了，上次没回答清楚。简单说就是，if语句是不满足条件就退出，while是不满足条件就等着满足条件。if条件满足之后之后return，会退出该方法。while之后是wait，没有return，所以并没有结束，只是当前线程进入了等待序列，当线程下一次获取cpu时间时还需要判断while里面的条件是否满足，才能执行下面的语句，所以需要while来反复判断。

是的，只是个资源

继续执行，不会重新开始的

线程3在没有争夺到锁的情况下肯定不会进入Wait Set等待了。这和你刚开始说的当线程1争夺到锁，而2、3没有争夺到时情况应该是一样的，CPU应该是还没有机会执行这条线程。一家之言。

使用UUID来创建唯一id，不会重复的

不会，在老师的例子中设置了单次转移能量的上限等于初始能量，因此至少有一条线程可以满足条件

感觉是不可以的吧，，我也是初学。不调用notify方法会导致等待区里的线程一直得不到释放，最终是否会导致等待区里的线程积压，运行的线程越来越少

女神指的是共享的内存资源，进程中的线程共享内存资源。

继续等待是防止线程重复的申请lock对象，一般的情况我们是直接结束该线程，这里是因为该线程是一直会重复执行的，所以为了避免更频繁的申请内存资源，所以加了一个等待；

synchronized是互斥，notifyAll是同步

操作系统中会有相应的算法避免这种死等的，有的要求在有限的时间内让线程访问。

没看到你别的代码,也没看这个题目,不知道具体问题, 但是就你出现的那个问题,notify是唤醒线程池中的任意一个线程,当你的读和取都有多个线程时,有使用的同一个锁,确实会造成死锁,

JDK1.5 java.util.concurrent.locks 包中提供了更方便的灵活的解决办法    

java.util.concurrent.locks包下    

Lock接口:代替了同步代码块或者同步函数,将同步的隐式锁操作变为了显示操作,而已可以加上多个监视器,

Condition接口中

signal();唤醒锁上指定监视器的一个线程 代替了notify()方法不会造成死锁   

不会，没有通知，一个set集如何知道要进行锁释放呢