博主分享了一次复杂的线程池调试经历，原本设计了多个线程却因难以控制而简化为单一线程，同时深入探讨了ByteBuffer的使用技巧及其陷阱。
这几天真是纠结呀，写个东西给搞的乱七八糟，设计了一个线程池，一个启动线程，一个控制线程，另外还有个日志线程，启动的时候要跑13个线程--！
感觉自己的程序就像是一堆零件拼起来的粗制滥造的机器，莫名其妙的接口，咬合和传送，随时可能会崩溃。
在一大堆线程中，用同步，sleep,wait,notify,join等绕来绕去。3天以后，还是几个顽固的异常，程序偶尔抽筋，执行顺序不可控，我抓狂了。于是删了12个线程，只留下一个，发现也能满足系统需求。
很多时候，我们需要的不是一个能造各种各种规格各种长度各种直径棍子从绣花针到金箍棒的机器，而只需要一个能砸人脑袋的铁棍。
话说就这最后一个线程，还有的折腾。
关键是这个对象，ByteBuffer，SocketChannel唯一接收的读写对象。
先前有讲到，ByteBuffer这个对象很不好用。一个弄不好信息就没了。网上找了很多资料，最后才搞清楚是flip问题。原来这个对象内部保存一个类似指针和游标之类的东西，指示当前操作位置。写完数据以后，这个指针就停留在当前写的byte那，也就是整个byte[]的最末尾。然后再去读的时候，从指针这开始读，自然就读不到了。所以写完了调一下flip()方法，把这个指针给放回去，这样才能读到。
于是觉得，ByteBuffer真不是个东西，用一下还要这么复杂，而且这个方法的说明还写这么难懂，什么翻转，根本就不对。一边念叨着一边狠狠的加上flip()，写完了加，读完了加，用完了再加，多置几次也不会出错，多多益善。
而这个动作，带来了另外一个非常隐蔽非常致命的问题。
未完待续
感觉自己的程序就像是一堆零件拼起来的粗制滥造的机器，莫名其妙的接口，咬合和传送，随时可能会崩溃。
在一大堆线程中，用同步，sleep,wait,notify,join等绕来绕去。3天以后，还是几个顽固的异常，程序偶尔抽筋，执行顺序不可控，我抓狂了。于是删了12个线程，只留下一个，发现也能满足系统需求。
很多时候，我们需要的不是一个能造各种各种规格各种长度各种直径棍子从绣花针到金箍棒的机器，而只需要一个能砸人脑袋的铁棍。
话说就这最后一个线程，还有的折腾。
关键是这个对象，ByteBuffer，SocketChannel唯一接收的读写对象。
先前有讲到，ByteBuffer这个对象很不好用。一个弄不好信息就没了。网上找了很多资料，最后才搞清楚是flip问题。原来这个对象内部保存一个类似指针和游标之类的东西，指示当前操作位置。写完数据以后，这个指针就停留在当前写的byte那，也就是整个byte[]的最末尾。然后再去读的时候，从指针这开始读，自然就读不到了。所以写完了调一下flip()方法，把这个指针给放回去，这样才能读到。
于是觉得，ByteBuffer真不是个东西，用一下还要这么复杂，而且这个方法的说明还写这么难懂，什么翻转，根本就不对。一边念叨着一边狠狠的加上flip()，写完了加，读完了加，用完了再加，多置几次也不会出错，多多益善。
而这个动作，带来了另外一个非常隐蔽非常致命的问题。
未完待续
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
