最近在并发上挖了一个坑，之前自己写的应用场景没有触发，但是同事用我的代码做升级版功能时就炸了，线上出现了几例不知原因的游戏卡死。好在同事足够牛逼且有耐心，辛苦打印日志后还是定位到了问题。根本原因还是在于当初我做设计时，对于并发的处理理解不够。
先简要描述一下问题再展开这一章节的内容吧，也是昨晚和同事讨论了很久并读了一下这一章节的内容才算是比较好的处理了该问题。
问题说起来还是挺简单的，就是对于共享数据访问冲突。涉及的功能模块是游戏的托管。托管机制大致思路是有一个线程以秒为单位一直在轮询托管任务队列，如果有任务满足托管任务条件就执行，用户离线时添加托管任务，牌局状态改变时修改托管任务状态。冲突的地方在于轮询线程和牌局状态改变时游戏线程同时修改共享数据。当初也考虑了可能有的冲突，以为用Collections.synchronized.... 结构就可以处理同步，结果报错时才发现，这个结构貌似确实是处理里同步，只是处理的方式是抛出异常，并非通过锁机制（这一句还需要查看源码确定是否真是这样）。而托管模块的代码，抛出的运行时异常会干掉托管进程，从而导致全盘托管失效。
后续解决方案是，把托管任务队列改成了单线程的，对于托管任务的添加、删除、修改和通知都添加了对应队列，为队列上锁，单线程执行不同操作队列。从代码分析上看觉得是完美解决了该问题。（实际效果还有待查证）
昨天读了一遍并发这章节，才发现其实可以更换思路来看待代码或功能模块。比如，我昨天所需要处理的问题其实核心而言就是共享数据线程安全的问题。站在这种核心问题的思路回看自己需要解决的具体问题，思路就会清晰很多。
第10章 并发
第66条 同步访问共享的可变数据
Java变量保证读或写一个变量是原子的，除非这个变量的类型是long或double。同步问题一个很重要的概念就是原子性，只有保证操作的原子性，才是同步安全的。
要考虑到虚拟机可能有的提升（hoisting）可能会调整代码的实际结构
读和写操作都没有同步时，静态数据的修改有可能不被其他线程所看到，这个时候volatile修饰符可以起到作用
结论是，当多个线程共享可变数据的时候，每个读或者写数据的线程都必须执行同步。
第67条 避免过度同步
如果执行某个很耗时的动作，应该设法把耗时动作移动到同步区域外边
过度同步的实际成本并不是指获取锁所花费的CPU时间，而是指失去了并行的机会
如果一个可变的类要并发使用，使这个类编程线程安全的，通过内部同步，可以比从外部锁定这个对象获取更高的并发性
第68条 executor和task优先于线程
现在关键抽象不再是Thread，它以前既充当工作单元，又是执行机制。现在工作单元的抽象是Task，Runnable和Callable。执行机制有executor service
第69条 并发工具优先于wait和notify
java.util.concurrent提供的并发工具分三种，Executor Framework、并发集合（Concurrent Collection）以及同步器（Synchronizer）
并发集合中不可能排除并发活动；将他锁定没什么通，只会使程序变慢
优先用ConcurrentHashMap而不是Collections.synchronizedMap或Hashtable
有些集合已经通过阻塞操作（blocking operation）进行了拓展
同步器使一些线程能够等待另一些线程的对象（很好用~）
小心线程饥饿死锁
第70条 线程安全的文档化
安全级别：不可变的(immutable) 无条件的线程安全(unconditionally thread-safe) 有条件的线程安全(conditionally thread-safe) 非线程安全(not thread-safe) 线程对立(thread-hostile)
第71条 慎用延迟初始化
主要是小心延迟初始化碰上多线程场景时出现的问题
第72条 不要依赖于线程调度器
最好的办法是确保可运行线程的平均数量不明显多于处理器的数量（想当年我在做豪门风云时创建线程的那股子豪迈呀 囧囧囧囧囧~~）
第73条 避免使用线程组
线程组貌似不是一个优秀的特性~~
网友评论