Featured Article

关于平台构建以及编程语言说明

个人简介 来自 2019年3月31日 下午6:27 发现自己很久没有更新博客的板式了,还是最初折腾了好多次再就没有更改,现在的主题倒是挺好看的,而… Read More »

重写线程池ThreadFactory接口实现对线程异常的捕获

在开发过程中经常会用到线程池,但创建线程池的方法都比较简单,使用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大小的线程池。

Java默认接口方法引发的多继承问题

Java8的这种改进源于接口升级迭代存在的问题,一旦在接口中新加入方法,异味着所有实现该接口的类都要实现该方法,例如List接口增加新的方法, ArrayList ,List, LinkedList, Vector以及所有相关的类都要发生变化,这简直就是灾难,对整个项目会产生非常大的影响,所以我理解Java开发者为了加入新的功能而又不影响现有代码的运行,容许接口中来编写默认方法,

SpringCloudGateway手动编写路由规则对请求进行转发

这篇文章主要是提供一种转发路由的代码实现方式,之前说的gateway都是使用配置文件来对请求进行路由,这样虽然很简单,但是不够灵活,如果后端对应很多服务实例,网关想要根据自己的规则来转发请求,比如编写不同的负载均衡策略,做一些特别的权重,以及在运行过程中动态的变更转发地址,这些用配置文件来做都不够灵活,没法自由的定义规则。

服务频繁发生YoungGC的处理过程(合理压测)

最近一直在做项目的GC优化,因为服务在运行过程中频繁发生GC问题,虽然不是FullGC,但Young频繁GC也会影响线上服务的性能,优化的方向有两个,1.修改JVM参数 ,2.优化代码逻辑。查看当前线上JVM配置调整年轻代的大小可以缓解因内存分配太小而发生频繁GC的问题。本次优化的重点在于代码逻辑的实现,

无状态节点服务的缓存数据同步实现

在目前需求背景下要设计一套底层服务系统,提供一系列基本数据请求接口,这里把该系统服务称为P,为保证高可用高可靠性,P系统最少依赖外部中间件,例如数据库消息队列等组件,服务所涉及的数据全部缓存到本地缓存中,然后由其他服务来请求接口或数据库收集数据,将收集的数据存入Redis中,再去通知P系统更新本地缓存的数据,收集数据的服务称为D。

MySQL与Redis中对LRU算法的使用

LRU也称为最近最少未使用算法,作为最常用的内存淘汰算法,在主流的系统中都可以见到相应的使用场景,而在MySQL与Redis中也有使用,可以说都是用来对存储空间进行管理,及时淘汰更新数据,提高存储空间利用率。

mysql自动合并索引(index merge)查询导致死锁问题

虽然在生产环境上加了分布式锁,但还是会出现某一个事务未结束,而下一个事务进入来修改数据,这时就会陷入等待,最后等待超时,事务进行了回滚,在运行几个月后第一次出现这种情况,发生死锁的是两条update语句,当sql语句的where语句中使用两个索引时,mysql的优化器可能会对这两个索引进行合并,使用explain分析会显示Using intersect(index1,index2); 表示将index1和index2合并来查询。该表中只有index1,index2两个索引。

缓存数据一致性如何保证

最近在思考的一个问题,如何保证缓存和数据库数据的一致性,防止出现类似于余额这种数据,在缓存里是1,而数据库修改为0后,用户再次发起扣费操作时,由于每次先会去判断缓存内余额的数据,缓存数据不一致,导致本应失效的一次请求被判断通过。这种情况在并发低的时候不太容易产生,当并发增大极有可能发生。

MySQL查询缓存与Innodb引擎的自适应哈希索引

MySQL与引擎之间更像是两套体系,相互之间协同提供更好的数据服务,查询缓存是MySQL在8.0版本之前提供的一个特性,当客户端与数据库连接完毕,需要执行查询语句时,查询缓存就会发挥作用,MySQL会将查询语句进行对比,如果之前执行过该语句,执行语句和执行结果会以键值对的形式被直接缓存到内存里,因为使用查询语句作为key,MySQL可以用语句来查询对应的key,在缓存中找到的话,就可以将key对应value的值返回给客户端,少去了后来再通过分析器,优化器,执行器,引擎等各个阶段复杂的处理。

Hash底层存储原理及优化Redis中big Hash的一些建议

Hash 是 Redis 中出现最为频繁的复合型数据结构,除了 dict 结构的数据会用到Hash外,整个 Redis 数据库的所有 key 和 value 也组成了一个全局Hash,还有带过期时间的 key 集合也是一个Hash。set集合相当于一个value为null的Hash,zset 集合中存储 value 和 score 值的映射关系也是通过 hash 结构实现的。