每周阅读（6/20）

文中提到了湾区日报的文章来源，值得参考和订阅。
湾区日报的文章都是从哪来的？

文章比较了各个序列化和反序列化方案，有一些是知名的开源项目或者相关的传输协议，比如：jackson，xstream，protobuf和thrift。
jvm serializers

文中谈了从黑客角度如何考虑API的安全性，以freelancer和携程的mobile app上暴露的API为例。
再看API设计——从黑客的角度

主要谈了连接池的实现，利用Apache的Commons Object Pool
数据库连接池的原理和Tomcat中的应用

the week of 2016/5/30

• 服务器开发那些事

the week of 2016/6/6

喜欢这种生活和工作态度，文中也提到了一些值得尝试的技术，例如：vue.js和Sematic UI。

• 2015，徘徊

关于微服务，文中提到了一些开源的项目，分别来自阿里，Netflix和Spring

• 实施微服务，我们需要哪些基础框架？

关于读书的5个误区：- So here are the 5 biggest reading mistake I see—and how to avoid them.
1. You read every text the same way: journal article, seminal book, original source, further reading, tables of data.，
2. You don’t want to miss anything out.
3. You want to remember it all.
4. You think ‘skim’ reading is cheating.
**5. You believe speed reading is the same as close reading, just faster. **

the week of 2016/6/13

Failsafe, 轻量级的容错框架，看readme api非常简洁。

Failsafe is a lightweight, zero-dependency library for handling failures. It was designed to be as easy to use as possible, with a concise API for handling everday use cases and the flexibility to handle everything else.

不谈架构，看看如何从代码层面优化系统性能

谈了常见的代码层面如何优化，例如：

使用Redis来做分布式锁。使用主键防重方法，在方法的入口处使用防重表，能够拦截所有重复的订单，当重复插入时数据库会报一个重复错，程序直接返回。使用版本号的机制来防重。必须要有过期时间，当锁定某一资源超时的时候，能够释放资源让竞争重新开始。
C3P0在大并发下表现的性能不佳。
Executors.newFixedThreadPool()在并发的情况下，无限制的申请线程资源造成性能严重下降，采用这种方式最大可以产生Integer的最大值个线程。Executors.newFixedThreadPool(50)虽然解决了产生无限线程的问题，但是当并发量非常大的时候，采用newFixedThreadPool这种方式，会造成大量对象堆积到队列中无法及时消费，因为采用的是有界队列(LinkedBlockingQueue)未指定大小就是Integer.MAX_VALUE，也就是说队列是可以无限的存放可执行的线程，造成大量对象无法释放和回收。方案1：因为服务器的CPU只有4核，有的服务器甚至只有2核，所以在应用程序中大量使用线程的话，反而会造成性能影响，针对这样的问题，我们将所有异步任务全部拆出应用项目，以任务的方式发送到专门的任务处理器处理，处理完成回调应用程序器。后端定时任务会定时扫描任务表，定时将超时未处理的异步任务再次发送到任务处理器进行处理。方案2：使用AKKA技术框架，下面是我以前写的一个简单的压测情况：
首先日志的打印必须是以logger.error或者logger.warn的方式打印出来。日志打印格式：[系统来源] 错误描述 [关键信息]，日志信息要能打印出能看懂的信息，有前因和后果。甚至有些方法的入参和出参也要考虑打印出来。在输入错误信息的时候，Exception不要以e.getMessage的方式打印出来。
以上三种方式都
Log4J的配置：%d %-5p %c [%t] - %m%n取代%d %-5p %c:%L [%t] - %m%n