有这么一个学校（Java虚拟机），里面有好多好多人（线程），简单分成学生、老师、以及宿管阿姨。
学校中间还有一个很奇葩的水果超市（临界区），里面有个仓库放着苹果、西瓜、橘子（临界区里的受保护资源）。
来这个超市的人，一方面可以拿走水果吃掉，另一方面也可以送来水果换钱。不过超市还有一个很奇葩的规则，就是学生只能去吃或者送苹果，老师则只能西瓜，宿管阿姨只能橘子。
这个超市的进出也很有规矩，来这个超市的人，必须持有相应的证件（锁对象），学生则需要持有学生证，老师需要持有教师证，宿管阿姨需要持有阿姨证（不同的锁对象）。
这三个证每个都分别只有一个，保管在超市门口的一个领证处（获取锁的地方--可以说是堆吧），人们进入这个超市之前，必须先去取证处那里领取相应的证件（获取锁）才能进入。
如果证件暂时被别人取走了拿不到（获取锁失败），则需要到后方的等待区（同步队列SychronizedQueue）里面排队等证。那这个等待区也有三个，分别是学生证等待区，教师证等待区，阿姨证等待区（每个锁对象对应一个同步队列）。
进入超市里面就更加奇葩了，不论是要从这个超市拿走水果，还是要送来水果，都需要通过一个操作台（单核CPU）来控制，而这个操作台，同一时刻只能有一个人进行操作。
这个操作台为了防止有人霸占操作台过长时间，只允许一个人持续操作10s钟（CPU时间片），10s之后会在屏幕上显示一个ID，只有这个ID的人才能来操作（线程切换）。
至于选择什么号码，老师、学生或是宿管阿姨都无法决定和干预，只能任凭这个操作台来决策（操作系统决定线程的切换和时间的分配）。但好在，每个人在操作台上都有自己的账号（线程的工作内存），操作一半被中断的数据并不会丢失。
这个故事的背景就介绍完了，下面这个学校就发生了各种各样的事。
首先假设，进这所学校的人，都是为了去超市做事情。首先人出现在学校外（线程状态NEW），人进入学校（线程状态RUNNABLE）。
某一时刻，操作台上显示了一个号码2号，这个号码通过各种学校大屏幕通知给所有的人。于是ID为2号的学生小明看到了自己的号码，得知自己获得了进入超市操作控制台的权利（获得CPU执行权），于是出发前往超市。
小明首先到超市门口，问领证处的管理人员，“给我一张学生证！”（获取锁）。管理人员找了找发现有一张学生证，于是便给了小明。
小明拿到了学生证，顺利进入超市（获取锁成功，进入临界区），并坐上了操作台前，登录了自己的账号系统（准备好工作内存，开始执行临界区代码），
小明此行的目的是为了拿走一个苹果，于是他点击了苹果商品的图标，系统显示苹果还有4个。于是小明顺利地拿走了苹果，系统将苹果数量-1，将新的苹果数量3记录到总系统库中（代码）。
接着小明走出超市（代码执行完毕出临界区），将学生证交还给了领证处（释放锁），走出了校园（线程状态TERMINAL），消失在人海中。
接着操作台上显示了3号，同样通过学校大屏幕通知给了所有人。ID为3号的学生小张看到了自己的号码，得知自己获得了进入超市操作控制台的权利，于是出发前往超市。
小张和小明做着完全相同的操作，但小张操作太慢了，刚刚点击完了苹果商品的图标，系统就显示了下一个人的号码5号。此时小张只能被迫终止自己的操作，让出操作台的权利（线程切换）。
ID为5号的学生小王接到通知，兴冲冲地前往超市，并在领证处问管理人员，“给我一张学生证！”。
管理人员找了找，发现学生证已经被小张取走了，只能告诉小王，“抱歉，学生证暂时没有，请到后面的学生证等待区（同步队列WaitQueue）排队吧！”（获取锁失败）。小王没办法，只能乖乖去排队了（线程状态BLOCKING）。
这时操作台再次显示了3号，也就是刚刚操作到一半的小张。小张此时还在超市里（不释放锁），并不需要重新进入，于是他赶紧到操作台前继续着刚刚的操作（线程切换，继续执行中断的代码），取走了一个苹果，离开了超市，交还了学生证（释放锁）。
此时领证处的管理人员收到了学生证，对着后面的学生证排队区喊，“学生证有啦，排队的人过来取吧！”（通知同步队列出队）。
正在排队等证的5号小王听到后，从排队的队列里出来，准备领证并进入超市。但此时操作台上显示的号是另一个学生10号，10号学生拿走了学生证，进入超市开始操作。
操作到一半，操作台时间限制又到了，显示了小王的ID 5号。小王刚从等待领证的队列里出来，终于获得了进行下一步行动的准许，于是走向了领证处，“给我一张学生证！”
由于学生证已经被10号拿走，管理人员只能说，“抱歉，学生证暂时没有，请到后面的学生证等待区排队吧！”
小王一看等了那么久居然又被别人抢先了一步，刚想爆粗口，想到了这个学校的名言，“这个世界是不公平的”，于是又乖乖走向了学生证等待区，继续排队。（非公平锁，并不是谁等的时间最长谁就获取锁）
等10号操作完出来了，还了学生证，小王又被领证处管理员喊话，“学生证有啦，排队的人过来取吧！”
小王走出排队区，而此时操作台终于显示了小王的号码5号。小王这次顺利领取了学生证，进入了超市，坐在了操作台上，登录了自己的系统。
小王想买苹果，于是点击了苹果商品的按钮，但系统显示苹果数量为0！小王此时想了想，有了个接下来的计划：
继续呆在超市里，得空就去操作台上查询一下苹果的数量，直到有苹果为止。
但继续呆在超市里，可能导致想向超市送苹果的学生拿不到学生证，而自己也就永远无法得到苹果了，显然不妥。（sychronized代码块里循环等待）
所以小王的另一个想法是，走出超市，交还学生证，等下次有机会再进入超市查看苹果数量，直到有苹果为止。
这样虽然有机会得到苹果，但太累了，假如这期间根本没人往超市送苹果，那这一趟趟其实是白费事的。（sychronized代码块外循环等待）
于是小王想出了一个聪明的方案，我可以走出超市，到一个地方等待（wait），在这里不会收到操作台的通知。如果有人向超市送苹果了，那这个等待区里会发一个信号（notify），这时超市才有可能是有苹果的，这时我从等待区里出来，等待叫号的机会。
虽然苹果有可能被其他吃苹果的学生抢没，但这样起码不会浪费太多时间。（等待通知机制）
刚刚好超市旁边为每一种水果准备了好多等待区（等待队列WaitQueue），一共有六个，分别是：苹果没了等待区，西瓜没了等待区，橘子没了等待区。苹果满了等待区，西瓜满了等待区，橘子满了等待区（条件变量Condition）。
小王很聪明，走出超市交还学生证（wait会释放锁），去了苹果没了等待区（wait），等待着有人往里送苹果的信号（同步信号-唤醒）。
这时小孙走进了超市，给超市添置了5个苹果，并换来了零花钱。之后他立刻通知苹果没了等待区，给了个信号“超市有苹果啦！（AppleNotEmpty.notifyAll）”，但此时小孙还没有走出超市呢（notify不释放锁）。
小王在等待区里收到信号，立刻走出了等待区，等待被叫号，以完成自己吃苹果的任务。但很不幸，在小王得到叫号机会之前，苹果又被其他几个学生抢光了，这时才轮到小王。
小王也很聪明，他考虑到了这种情况，没有直接取苹果，而是重新查询了一下苹果数量（wait一般配合while条件），发现苹果数量为0，于是重复之前的步骤，小王再次回到了苹果没了等待区。
接下来的时间里，小王不断在苹果没了等待区和学生证等待区移动，小王发现为了吃一个苹果太难了，必须同时满足，苹果没了等待区发来了“超市有苹果了”的信号，领证区此时有学生证，并且在操作台上查询出的苹果数量不为0。
终于有一次。小王成功满足了这三个条件，在操作台上看到苹果的数量为1！小王正激动地准备按下购买按钮，可此时操作台一闪，突然出现了别人的号码。
这个人是超市管理员，拿着一张特殊的超市管理员证顺利进入了超市，将苹果拿走，此时苹果数量又变成了0。
之后又轮到小王操作，但小王并不知道之前发生的一切，他眼中明明看到苹果数量是1。小王为了保险起见，又多次查询了苹果数量，发现仍然是1（非volatile修饰的变量不保证线程之间的可见性），于是兴奋地点下了购买按钮！
于是，操作台对根本没有苹果的储藏区发出了取苹果的指令，该系统根本没有想到会有这种事情发生，于是机器炸了，小王牺牲（抛出运行时异常，线程终止并释放锁）。
数年后，之前做操作台的人已经被枪毙了，学校又高薪聘请了一位高人来建造，解决了之前的那个问题（volatile）。
超市又顺利运转起来，有时超市只有一个人（不同线程进入锁对象相同的临界区会互斥，只有一个线程可以进入），有时超市会有三个人（不同锁对象的临界区不互斥），分别是学生、老师、宿管阿姨，他们仨人互不影响，相安无事。学校的生活再次丰富了起来。
