并发多线程
文章平均质量分 84
zzzgd816
这个作者很懒,什么都没留下…
展开
-
lua脚本实现滑动窗口的分布式全局限流器, 控制api接口qps
限流器, 从算法实现的角度来说, 就我知道的常见的有 滴漏桶, 令牌桶, 滑动窗口计数,固定窗口计数法从实现的工具来说, 常见的有 guava的 RateLimiter (令牌桶)redis的每秒或者每一分钟过期时间的incr(固定窗口计数)但是这些大多数时候都被我们用来当做单个机器上的限流措施, 尤其是guava这种单体框架. redis的incr虽然能控制全局, 但是还是有问题.原创 2023-04-10 21:02:01 · 1132 阅读 · 1 评论 -
【踩坑】parallel并发流导致数据异常
慎用parallel和parallelStream如果非要用, 确保里面不会对同一个元素修改如果非要修改, 确保元素是有同步修饰的, 或者Atomic类的对于数据量不大的, parallel可能更耗时间, 因为线程的切换,以及parallel是先切分list再合并, 切分合并也需要时间parallel后会导致list无序。原创 2022-11-25 19:44:22 · 1192 阅读 · 0 评论 -
【踩坑】慎用线程池,导致生产环境假死
线程池最好统一管理起来,不要随便new,或者new了用完记得关闭,或者使用jdk提供的ForkJoinPool等框架自带的,或者写单例线程池的线程数,队列大小需要考虑,不同的场景(IO密集和CPU密集)应该用不同的线程池。队列太长,可能难以触发增加线程数到maxThread,导致在等待时间过长,超时。队列太小,则需要考虑maxThead大小,避免线程不够用。原创 2022-11-22 18:52:24 · 1216 阅读 · 0 评论 -
ConcurrentHashMap的jdk1.7和1.8区别整理
ConcurrentHashMap的jdk1.7和1.8区别整理初始化jdk1.7Segment个数HashEntry个数jdk1.8put()方法jdk1.7jdk1.8get()方法jdk1.7jdk1.8size()方法jdk1.7jdk1.8resize()方法jdk1.7jdk1.8主要区别:1.7 采用的是分段加锁, Segment(区段) + HashEntry + Unsafe1.8 撇弃了Segment, 锁的粒度细化到具体每个桶上的头结点, 并加上CAS和Synchronize加原创 2021-10-29 17:25:42 · 490 阅读 · 0 评论 -
简单总结jdk1.7HashMap扩容死循环和jdk1.8优化
简单总结jdk1.7HashMap扩容死循环和jdk1.8优化jdk1.7 HashMap死循环原因扩容步骤死循环总结jdk1.8的改进jdk1.8仍然存在的问题网上很多关于jdk1.7HashMap扩容死循环的博客, 但是很多都是贴了大量的代码和图, 这里只进行简单概括总结, 详细的还是需要自己看源码.jdk1.7 HashMap死循环原因首先贴代码 (这个必要的还是要贴) void resize(int newCapacity) { .... transfer(ne原创 2021-10-27 12:17:31 · 799 阅读 · 0 评论 -
代码实现用直观的方式来检查锁Lock是否线程安全
代码实现用直观的方式来检查锁Lock是否线程安全代码操作读写文件的任务类测试类测试不加锁加锁补充这几天在看分布式锁,照着博客手写一个分布式锁也好, 直接用框架也好,怎么验证写的是否保证线程安全?有个传统的就是多线程循环对一个int变量进行 i++,然后看最后的结果是否符合预期。int n=0;for(int i=0;i<1000;i++){ n++;}//最后判断找到了另一个方法,先看效果:没错, 跟循环i++差不多, 这个是循环取最后一行, 拼接字符串加一个星号, 在写入到文件原创 2020-06-30 18:56:24 · 351 阅读 · 0 评论 -
从数据安全的角度解决高并发下秒杀问题(以及redis连接池并发下问题)
从数据安全的角度解决高并发下秒杀问题这个是博主自己闲的无聊的时候想写个demo玩玩,并不算最好的解决方案,当然也是阉割了很多东西的简化版,现实业务肯定比这个复杂这里的话不考虑高并发带来的性能问题,什么负载均衡,限流,分发请求等。就考虑如何保证商品的库存不会超卖。一、思路秒杀下的数据安全,无非是两个角度,一是商品库存,不能超卖;二是用户秒杀,一般来说都不会允许同一个用户秒杀两次先简单说说思...原创 2019-07-30 19:28:08 · 2327 阅读 · 0 评论