摘要:1 背景 如果将mybatis guice 事务代理切面 中的endTransaction注释掉,那么将会有连接泄漏,本文是一个实践 private void endTransactionReal() { //getOdsSqlSessionManager().close();} 2 2.1 连接池
阅读全文
摘要:1 背景 1.1 生产环境几次所有操作出现 [java.lang.RuntimeException: java.lang.OutOfMemoryError: Failed creating thread: pthread_create() failed, maxproc limit reached]
阅读全文
摘要:还是来看这张图: 由于此前redis分布式锁超时事故,所以中间那个线程池设置为有界队列,并配置了放弃策略,故当disruptor消费者不给力时,经阻塞模式的disruptor逆推到生产者阻塞,导致堆积的线程超出队列上限被放弃 那为什么消费者会不给力? 在消费者中,消费频率大约是一个合约每秒4次,在2
阅读全文
摘要:项目突然改为多生产者 中间的线程池默认为single,突然改为3,导致有3个线程同时往disruptor生产数据 多生产者 ringbuffer采用cas抗并发,而单生产者没有 当时开启了3个线程来生产消息,而并没有用多生产者模式
阅读全文
摘要:1 突然改成多线程行情消费者,导致并发,重复成交 还有一个方案:成交后投递到mq,由mq消费者单点消费排重后处理成交 /Users/joyce/work/jds/trade/simulate-trade/tradeEngine/src/main/java/com/jds/engine/listene
阅读全文
摘要:说明: 1) 读写的数据结构包含:持仓、盈亏 2部分 虽然浮动盈亏这块没有更新持仓,仅更新了盈亏,但写入时又把读出来的原持仓写回去了 成交读取pb持仓 浮动盈亏读取pb盈亏 处理持仓 处理盈亏 写入pb持仓 写入pb盈亏 所以,读取和写入的内容粒度应细,这也关系到排他锁的粒度这里如果将持仓与盈亏分开
阅读全文
摘要:redis分布式锁有两层超时: 1 锁等待超时 2 tcp connection超时 任一个超时未设置,都有可能造成阻塞 事故如下: *disruptor采用阻塞模式,到最大消息池时即阻塞,导致线程阻塞 左下角,获取redis锁虽然使用了trylock立即返回,但是没想到,由于断网,redis客户端
阅读全文