给自己写的程序条毛病(r12笔记第68天)

  
前几那天写了一个Java程序模拟生产者消费者，当时写完还感觉不错，但是这几天再看的时候发现还是有很多的不足之处，给别人挑毛病不大好意思，尺度拿捏不好还容易得罪人，男人就对自己狠一点，我就给自己多挑挑程序的毛病，这个可以有，有些细微的毛病就马上改了，有些有难度的，我也记录下来，不断的改进，看起来简单的程序写好了才算是一个合格的程序员。

   感兴趣的同学可以移步这里，看看之前写的程序。

http://www.toutiao.com/i6420749007307407873/

   我大体总结了下，从日志中可以看出有这么几个明显的小问题。

1. 第一种模式和第二种模式的线程数不同，明显第二种模式的线程日志有长得多。
2. 第二种模式的消费者申请的消费产品数和规格不符，应该为10的倍数，第二种模式没有取整，这样看起来不是很清晰。
3. 第一种和第二种模式，生产者和消费者对应的产品数不能为0，这种场景其实不应该存在的，所以就可以考虑从随机数或者从对象层级进行校验，至少规范来看，入参要规范，所以我从随机数生成逻辑上进行校验控制。
4. 生产线程和消费线程虽然是动态生成，但是从日志可以看到有明显的串行执行的痕迹，可以把这个过程做成真正的动态，库存不足，生产者生产，库存充足，消费者消费。如果把生产者消费者这个模型看做是一个系统，就好比一个齿轮，一个直接的目标就是让齿轮转动的快。
5. 无论第一种模式还是第二种模式，如果碰到条件不满足的情况就会存在等待的情况，这个等待的频率可以借鉴一些数据库层面的经验，来优化控制一下，比如第一次等待，sleep多少毫秒，第二次sleep多少毫秒，这样有一个基本的控制范围，减少中断的次数。
6. 这个库存其实就像MySQL面刷脏页一样，脏页数达到多少的时候来触发生产者生产，能够尽可能减少生产者等待的频率，提高消费者消费的频率。
7. 其实目前的实现，如果细细想来，原本生产者消费者的性能瓶颈现在落到仓库上，但是目前仓库应该有几个门，控制入库，控制出库，而不能总是在一个门里，要么把门加宽，要么多加几个门，入口和出口分开。
8. 为了尽可能提高吞吐量，整个实现过程也可以考虑通过事务的方式来控制，比如放到一个仓库的表里，对于数据进行实时的变更和查询，或者使用其他的数据结构。
9. 为了尽可能突破单个仓库的瓶颈，可以考虑设置多个仓库，这样库存能够大大大提高，而且是一个线性扩展的方式，当然这就会引进更多的考虑和方案
10. 尽可能提高消费者线程的使用率，比如考虑使用线程池等等方式来实现。

  最后硬凑一个观点吧，那就是一个牛叉的程序构思好了，能够在短时间内实现出来，光说不做太虚，能说能做才是真。

  或者说你有更多的建议，也给提提吧，感激不尽。