首页
沸点
课程
数据标注
HOT
AI Coding
更多
直播
活动
APP
插件
直播
活动
APP
插件
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
登录
注册
确定删除此收藏集吗
删除后此收藏集将被移除
取消
确定删除
确定删除此文章吗
删除后此文章将被从当前收藏集中移除
取消
确定删除
编辑收藏集
名称:
描述:
0
/100
公开
当其他人关注此收藏集后不可再更改为隐私
隐私
仅自己可见此收藏集
取消
确定
jvm
订阅
自己争取
更多收藏集
微信扫码分享
微信
新浪微博
QQ
4篇文章 · 0订阅
Spring解决泛型擦除的思路不错,现在它是我的了。
你好呀,我是歪歪。 Spring 的事件监听机制,不知道你有没有用过,实际开发过程中用来进行代码解耦简直不要太爽。 但是我最近碰到了一个涉及到泛型的场景,常规套路下,在这个场景中使用该机制看起来会很傻
高并发场景下JVM调优实践之路
高并发场景下JVM调优实践之路。通过监控发现,接口响应慢主要是P99耗时高引起的,怀疑与该服务的GC有关,典型的GC调优
一次ygc越来越慢的问题排查过程
某天突然收到线上应用的gc时间过长的告警,刚开始只有一台机器偶尔报一下,后续其他机器也纷纷告警,具体告警的阈值是应用10分钟内ygc的总时长达到了6.6s。 按照gc问题常规排查流程,还是先保留现场,jmap -dump:format=b,file=temp.dump pid。…
记一次艰难的GC问题排查!
背景 gc问题一直是一个很难排查的问题,但是他又是一个经常在我们开发业务中出现的。这不,最近在我的项目中就出现了一个比较奇葩的gc问题,排查过程比较繁琐,所以在这里分享一下这个整个排查过程,希望对大家