在开发过程中经常会用到线程池，但创建线程池的方法都比较简单，使用Executors来创建相应功能的线程池，常用的方法有这些。 “` 1、 Executors.newFixedThreadPool(int nThreads);创建固定大小(nThreads,大小不能超过int的最大值)的线程池 2、Executors.newSingleThreadExecutor()：创建大小为1的固定线程池。 3、Executors.newCachedThreadPool()；创建corePoolSize为0，最大线程数为整型的最大数，线程keepAliveTime为1分钟，缓存任务的队列为SynchronousQueue的线程池。 4、Executors.newScheduledThreadPool(int corePoolSize):创建corePoolSize大小的线程池。
Java8的这种改进源于接口升级迭代存在的问题，一旦在接口中新加入方法，异味着所有实现该接口的类都要实现该方法，例如List接口增加新的方法， ArrayList ，List, LinkedList, Vector以及所有相关的类都要发生变化，这简直就是灾难，对整个项目会产生非常大的影响，所以我理解Java开发者为了加入新的功能而又不影响现有代码的运行，容许接口中来编写默认方法，
这篇文章主要是提供一种转发路由的代码实现方式，之前说的gateway都是使用配置文件来对请求进行路由，这样虽然很简单，但是不够灵活，如果后端对应很多服务实例，网关想要根据自己的规则来转发请求，比如编写不同的负载均衡策略，做一些特别的权重，以及在运行过程中动态的变更转发地址，这些用配置文件来做都不够灵活，没法自由的定义规则。
最近一直在做项目的GC优化，因为服务在运行过程中频繁发生GC问题，虽然不是FullGC，但Young频繁GC也会影响线上服务的性能，优化的方向有两个，1.修改JVM参数 ，2.优化代码逻辑。查看当前线上JVM配置调整年轻代的大小可以缓解因内存分配太小而发生频繁GC的问题。本次优化的重点在于代码逻辑的实现，
在目前需求背景下要设计一套底层服务系统，提供一系列基本数据请求接口，这里把该系统服务称为P，为保证高可用高可靠性，P系统最少依赖外部中间件，例如数据库消息队列等组件，服务所涉及的数据全部缓存到本地缓存中，然后由其他服务来请求接口或数据库收集数据，将收集的数据存入Redis中，再去通知P系统更新本地缓存的数据，收集数据的服务称为D。
虽然在生产环境上加了分布式锁，但还是会出现某一个事务未结束，而下一个事务进入来修改数据，这时就会陷入等待，最后等待超时，事务进行了回滚，在运行几个月后第一次出现这种情况，发生死锁的是两条update语句，当sql语句的where语句中使用两个索引时，mysql的优化器可能会对这两个索引进行合并，使用explain分析会显示Using intersect(index1,index2); 表示将index1和index2合并来查询。该表中只有index1,index2两个索引。
最近在思考的一个问题，如何保证缓存和数据库数据的一致性，防止出现类似于余额这种数据，在缓存里是1，而数据库修改为0后，用户再次发起扣费操作时，由于每次先会去判断缓存内余额的数据，缓存数据不一致，导致本应失效的一次请求被判断通过。这种情况在并发低的时候不太容易产生，当并发增大极有可能发生。
Hash 是 Redis 中出现最为频繁的复合型数据结构,除了 dict 结构的数据会用到Hash外,整个 Redis 数据库的所有 key 和 value 也组成了一个全局Hash,还有带过期时间的 key 集合也是一个Hash。set集合相当于一个value为null的Hash，zset 集合中存储 value 和 score 值的映射关系也是通过 hash 结构实现的。
本来想说ThreadLocal，但看到了ThreadLocalMap中对哈希碰撞是采用开放寻址法来实现的，觉得很有意思，hash使用的场景很多，散列表就是一种高效而常用的数据结构，能将查找的时间复杂度降到O(1)，它通过哈希函数来生成一个 hashcode 值，从而对数据进行一一定位，虽然现在的哈希函数已经能做到很好的随机，但还是会有冲突发生，也就是不同的对象经过哈希函数的计算，生成了相同的 hashcode 值。当哈希冲突发生时，一般有以下几种方式来处理：
当微服务由单机部署变为分布式集群部署，在业务中涉及的一些数据库操作或者其他可能存在并发问题的地方，都有可能因为代码层面考虑不周或存在漏洞，导致数据丢失更新，数据不一致的问题发生，我也是在工作中遇到这个问题。例如A请求查询数据库中可用次数为100，此时B请求也查询数据库中可用次数为100，A请求进行-1之后在数据库中修改为99，而B请求也-1之后修改数据库中可用次数为99，这时就发生了数据丢失更新的问题，给公司造成了损失，当并发量更大，B请求出现一定延时，可能会发生其他请求已经修改了十多次，而B请求又将可用次数改为99，如此日积月累会造成巨大的损失。