发信人: KingOfWater (水人), 信区: CPlusPlus
标  题: 植物大战僵尸 这样的游戏是怎么写出来的？
发信站: 水木社区 (Mon Aug  2 12:52:05 2010), 站内

昨天看女朋友玩的时候，突然想了这个问题：
每个僵尸或一个植物都是一个线程控制的么？

2
发信人: RoachCock (我的饭盒我的饭), 信区: CPlusPlus
当然不是，你可以想象有一个时间流，万事万物都是每个时间间隔重新计算状态，都是被驱动的。

3
发信人: KingOfWater (水人), 信区: CPlusPlus
非常谢谢
你这句话说的太有哲理了
万事万物的构造啊
其实程序员某种程度上讲就是上帝！

5
发信人: RoachCock (我的饭盒我的饭), 信区: CPlusPlus
感觉宇宙也是，每过一个普朗克时间（10的负46次方秒），宇宙中的每个夸克就重新计算一下状态，看起来我们就活起来了。

12
发信人: RoachCock (我的饭盒我的饭), 信区: CPlusPlus
自从发现普朗克时间和普朗克长度，我就深信宇宙是在数字计算机里虚拟出来的。

 灭绝师太年轻时也曾经是个充满憧憬和梦想的女生，但是后来两次悲剧的恋爱失败，终于导致性格扭曲，并且和明教结下大仇。引自金庸初版书中的段落：

    俞莲舟道：「不是。」他顿了一顿，道：「前辈的私事，咱们原不该背后谈论。只知灭绝师太少年时是武林中出名的美人，后来她忽然出家为尼，方老英雄便自断一臂，终身不娶。」张翠山和殷素素同时「哦」了一声，明白灭绝师太和方老英雄少年时想是一对情侣，不知为了什么缘故无法成婚，于是一个出家，一个便断臂以报。临到老来，方评竟为谢逊杀害，灭绝师太自非替他报仇不可。


    灭绝师太听到杨逍两字，突然跳起身来，袍袖一拂，喀喇喇一响，一张板桌给她击坍了半边。张无忌已躲在屋外偷听，固是给她吓得大吃一惊，纪晓芙丁敏君等三个弟子也是各各脸色大变。灭绝师太厉声道：「你说他叫杨逍？便是明教的大魔头，自称什么『光明使者』的杨逍么？」纪晓芙道：「他……他是明教中的，好像在教中也有些身份。」灭绝师太满脸怒容，问道：「他……他躲在那里？我去找他去。」纪晓芙道：「他说他在昆仑山的『坐忘峰』中隐居，不过只跟弟子一人说知，江湖上谁也不知。师父既然问起，弟子不敢不答。师父，这人……这人是本派的仇人么？」灭绝师太道：「哼，岂仅是本派的仇人而已。你大师伯孤鸿尊者，昆仑派的名宿游龙子，便是给这个大魔头杨逍活活气死的。」纪晓芙心中甚是惶恐，但不自禁的也隐隐感到骄傲，孤鸿尊者和游龙子都是名扬天下的高手，居然会给「他」活活气死。她想问其中详情，却又是不敢出口。她们峨嵋弟子，均知师父和大师伯孤鸿尊者是师祖座下的两大弟子，却不知这两人情爱甚笃，原有嫁娶之约，只是孤鸿尊者中道殂逝，灭绝师太这才削发为尼。

找到1Q84，试着读了一点，竟然觉得挺合胃口。以前读村上的书，虽然不讨厌，但也不是非常读得下去。恍惚之间就是六七年；这时间改变了谁，是村上变了还是我变了呢

我越来越接近小资了。

今天手贱，

看了一个《淘气少女求爱记》

张娜拉在里面饰演了了一个极度花痴脱线的女人。

彻底毁掉了张娜拉在我心中的美好形象。

再见了，我唯一的最后的偶像。

wait()放while里面算是一个常识性的准则。为什么要这样呢，如果放到if里面会有什么后果？今天水木有人贴出了一段出错的代码，对这个问题现身说法：

public class A {
        private Object[] queue = new Object[1024];
        private int cMsg;

        public synchronized boolean accept(Object msg, Object token)  {
                if (cMsg >= queue.length) {
                        try {
                                wait();
                        }
                        catch (InterruptedException e) {
                                return false;
                        }
                }

                queue[cMsg++] = token;
                queue[cMsg++] = msg;
                return true;
        }

        public synchronized Object[] getMessages()  {
                if (cMsg == 0) {
                        return null;
                }

                Object[] tmp = (Object[]) Arrays.copyOf(queue, cMsg);
                Arrays.fill(queue, 0, cMsg, null);
                cMsg = 0;
                notify();
                return tmp;
        }
}

这个代码在大并发下测试，抛出了java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 1025异常。

要分析原因的话，就是wait()被唤醒后，队列已经满了，cMsg >= queue.length这个条件已经不满足了，再往后移下标的话就数组越界了。

问题是为什么wait()唤醒后队列会满。在代码里，将队列清空后，才执行notify()，这个时候它应该只唤醒了一个线程，那么谁把队列填满的呢

答案是一个阻塞在accept上面的线程。首先要知道一点：其他线程收到信号并不是在notify调用的那一刻！notify的信号是在退出同步函数后才发出的，从退出同步函数，到信号发出，这中间有个时间差，因而就有可能出现以下执行序列：

1. getMessages方法中的 notify()调用
2. getMessages退出，此线程A释放类实例上的monitor
3. 一个阻塞在accept上的线程B，得以进入accept方法，因为此时数组被清空，线程B填入数据，下表+2;accept不断的调用，直到数组被填满，而阻塞在wait()调用上
4. notify信号发出，一个线程C被唤醒。这时没有再判断数组下标位置，直接想数组中塞数据，数组越界。

解决这个问题的方法当然就是把if改为while：

                while (cMsg >= queue.length) {
                        try {
                                wait();
                        }
                        catch (InterruptedException e) {
                                return false;
                        }
                }

在被唤醒后，重新判断条件是否满足。

经常，我们启动了一组线程，让他们去工作，并等待他们完成，获取他们的返回结果。为了保证程序不会卡死在这些线程的执行上，我们为线程设定了一个超时时间，希望线程如果超过这个时间没有完成，就终止执行。

在线程启动的时候，为其建立一个定时器就可以计算超时时间了。那么，问题就是，如何在一个线程已经超时的时候，停止这个线程的执行。

这是个从线程出现以后就在纠结的问题。

Java最初提供了一个Thread.stop方法用于终止线程，但是这个方法随后就因难以解决的线程安全问题被标记为deprecated，不建议继续使用。Thread.stop的原理是让线程抛出ThreadDeath异常(确切的说，它是一个Error)，由于程序都不会捕获这个Error，所以这个线程依次退出调用栈，最终退到栈底而终止。在退栈的过程中，会执行所有的finally代码块，并释放线程持有的所有的锁！看起来这是一个设计相当完美的方案，当初那帮设计者应该会被自己的聪明智慧感动得流泪了吧。然而在实际使用的时候，由于被终止的线程释放了所有的锁，被这些锁保护的对象都变得可以被其他线程所访问，从而引发了意想不到的问题——问题可大可小，可能根本察觉不到，也可能造成莫名其妙的错误。

在剥夺了Thread.stop方法后，JDK转而建议使用共享条件变量来控制线程退出，就好似这样：

Class MyThread extents Thread{

    public volatile boolean stop = false;

    public void run(){
        dosomething1();
        if(stop){
            return;
        }

        dosomething2();
        if(stop){
            return;
        }

        dosomething3();

    }

}

需要停止时只要此线程的stop设为true就行了。这需要小心翼翼的编码，如果在最耗时的操作中间没有对退出标识进行判断，那所有其他的工作也就是白费了。

设置条件变量仍然没有办法处理线程被阻塞的情况(如调用Object.wait()、ServerSocket.accept()和DatagramSocket.receive()等方法时)。一个阻塞中的线程是没法检查条件变量的，它只有等到条件满足，解除阻塞时，才能对条件变量进行判断。这时候可以调用Thread.interrupt方法打破阻塞。Thread.interrupt会使目标线程抛出InterruptedException异常，这个异常通常在代码中被捕获，线程因而跳过阻塞的请求，继续执行。

所以应如下停止一个线程：

MyThread thread = new MyThread();
//wait for some time.
thread.stop = true;
thread.interrupt();

事情还没有完。有些阻塞的线程是不响应Thread.interrupt方法的(例如阻塞在socket.accept() 等旧式IO请求上)，Thread.interrupt可以打断的阻塞调用只有Object.wait, Thread.join和Thread.sleep三种。对于这些情况没有通用的处理方法，只能却别对待。例如对于阻塞在socket.accept()的线程，我们可以调用socket.close()来接触阻塞。需要说的是，这种不响应Thread.interrupt的阻塞线程，也不会响应Thread.stop。

综上：多线程是强大的工具，但是也面临很多难以解决的问题，停止正在执行的线程就是其中之一。

Firefox Sync是Mozilla官方的firefox同步插件，已经可以同步书签、密码、历史、配置等信息，功能挺强。

但是不久前，Firefox Sync新发布的1.4版本，被很多人称作是一个disaster。基于某些开发人员奇特而固执的思维，Firefox Sync做出了如下不可思议的改动：

1. 取消了在状态栏的状态图标显示和弹出菜单。仅仅在菜单栏里保留了一个sync now的菜单，当你点击这个菜单后，不会有任何反馈(连个同步完成的提示框都没有)，就好像什么事情都没发生过。用户无法得知自己同步的状态，不知道是否同步成功，甚至不知道是否连上同步服务器……

2. 默认不自动同步。甚至默认不会连接同步服务器！很多人直到发现自己的书签在多台计算机上不一致的时候，才知道Firefox Sync它根本没有工作！必须要你去手动点一下。

这些改动招致了无数的反对意见。神奇的Firefox Sync开发团队起初居然还和用户争论，试图说明这种改动是经过深刻考虑的、用户体验良好的、更加安全的。真希望我是他们的老板然后开除他们。

将来的1.5版本预计会修复这些问题，等着观察他们的表现。

昨天的时候一个小姑娘过来面试，过半的时候，随口问她住在哪里，结果她说现在在珠海工作，是接到了面试通知之后，飞过来的。其实当时基本上已经决定据了她了，这后面的面试过程我相当揪心，似乎我是个很邪恶的人。完了跟她说，有这种情况，你先要个电话面试就好了啊。

我真是有点多愁善感了。一个小姑娘，为了一个渺茫的希望，请假从珠海飞到北京来面试。其实不知道她之前找工作的经验怎样，以我面试的经验来说，面试十个公司能得到两个满意的offer已经是很不错的了。这还是我这样非常优秀的，非常聪明的，有经验的开发人员所遇到的情况。

这小姑娘应该已经明白结果了，赶晚上的飞机回去了吧。希望以后不要这么鲁莽了。