Category Archives: JAVA

重写线程池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。

从TheadLocalMap看哈希碰撞后开放寻址法的实现过程

本来想说ThreadLocal,但看到了ThreadLocalMap中对哈希碰撞是采用开放寻址法来实现的,觉得很有意思,hash使用的场景很多,散列表就是一种高效而常用的数据结构,能将查找的时间复杂度降到O(1),它通过哈希函数来生成一个 hashcode 值,从而对数据进行一一定位,虽然现在的哈希函数已经能做到很好的随机,但还是会有冲突发生,也就是不同的对象经过哈希函数的计算,生成了相同的 hashcode 值。当哈希冲突发生时,一般有以下几种方式来处理:

对于mysql,redis,Kafka,zookeeper磁盘缓存技术使用分析

大部分组件是基于磁盘存储的,但由于CPU速度和磁盘速度之间的鸿沟,都会使用缓存技术来提高性能,缓存简单来说就是一块内存区域,首先将从磁盘读到的数据放在缓存中,之后查询或修改时直接操作缓存,对于缓存中的数据则以一定的频率刷新到磁盘上,怎样缓存,缓存多少,何时刷新,这些影响着整个组件的性能。在看过一些关于mysql等组件的架构原理后,会发现不论是基于磁盘的mysql数据库和Kafka消息中间件zookeeper分布式协调框架,还是基于内存的redis数据库,它们都设计了完善的内存和磁盘之间数据交互实现。

SpringCloud-Gateway对multipart/form-data等其他POST请求类型的body体进行多次打开

本次代码仅在以下版本中测试通过

这几天在用g… Read More »