读码农翻身之我是一个线程

1、线程

“我们的世界规则很复杂，首先你不知道什么时候会被挑中执行；第二，在执行的过程中随时可能被打断，让出CPU车间；第三，一旦出现硬盘、数据库这样耗时的操作，也得让出CPU去等待；第四，就是数据来了，你也不一定马上执行，还得等着CPU挑选。”

小结：
1、线程不知道什么时候会被选中执行：个人感觉应该是存在着某种算法，通过这种算法来让线程进入就绪状态。
2、执行过程中随时可能被打断：这是因为CPU的速度极快，所以cpu通过不断切换线程的方式，来欺骗人类。然人类以为程序是同时进行的。

2、线程池

平淡的日子就这么一天天地过去，作为一个线程，我每天的生活都是取包裹、处理包裹，然后回到我们昏暗的家：线程池。

小结：线程池的主要作用，其实就是为了让CPU能减少每次创建线程的资源消耗。

3、缓存

他建议我：“你一定要和memecached搞好关系，直接从他那儿拿数据，尽量少直接调用数据库，这样我们JDBC connection也能活得轻松点。”
我欣然接纳：“好啊好啊，关键是你得提前把数据搞到缓存啊，要不然我先问一遍缓存，没有数据，我这不还得找你吗？”

小结：这里其实就设计到了系统架构中缓存的重要性！因为从缓存中取数据比从数据库中取数据是要快很多的！不过实际工作中，我们用的大部分情况是redis。曾经还有项目中我们只使用了redis来作为数据库，而没有用传统的关系型数据库。当然，各有优劣。关系型数据库的优势是通过sql来很好的得到我们想要的结果，而使用redis的速度快，但是扩展性不好。个人感觉还是redis做临时缓存更加合适。

4、锁

“多个资源加锁要牢记，一定要按Boss的算法比大小，然后从最大的开始加锁。”

小结：这个地方的例子我感觉很经典。就是在加锁的时候，是需要考虑到优先级的！如上图所示，获取锁的双方都需要进行等待，而正是这种等待，会造成死锁。而且这种问题如果是在实际项目中，肯定很难发现！当然，解决方案也是有给出来的。就是通过算法，即如果某个操作需要涉及到多个用户时，双方在获取锁的时候需要先通过相同的算法计算出要先给哪个用户加锁。这样，就能避免这个问题了！