Jedis的socket内存泄露的这些坑，别说你没遇到过！

最新推荐文章于 2025-04-16 16:49:56 发布
最新推荐文章于 2025-04-16 16:49:56 发布
阅读量1k 收藏 2
点赞数
分类专栏： 经验总结 文章标签： java jedis 编程语言 程序人生 经验分享
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_42032431/article/details/107714183
版权
本文详细介绍了在业务线上环境中遇到的Jedis导致的Socket内存泄露问题，通过步骤分析了问题的原因，包括Jedis连接池配置、 Commons-Pool的空闲对象驱逐机制以及Finalizer对内存回收的影响。最终，作者强调了不应忽视任何微小问题的重要性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

本文是关于Jedis的socket内存泄露问题排查的分享。

背景

业务线上有N台机器。其中有一台会缓慢的出现Socket内存泄露。具体表现为在jmap时会常常看到如下类排名很靠前。

5: 274623 30757776 java.net.SocksSocketImpl 8: 274621 13181808 java.net.SocketInputStream 9: 274621 13181808 java.net.SocketOutputStream 17: 274621 8787872 java.net.Socket 21: 274668 6592032 java.net.Inet4Address

从占用数量以及内存情况来说。其实完全是可以接受的。但是不能理解的是为什么就单独这台机器占用偏高。其他机器也有一定的数量，但是和这台机器差别较多。

STEP0

这一台机器唯一和别的机器不同的是：

该机器周期性的在本机进程内执行一些数据逻辑。每5分钟调度一次，每次大概执行1分多钟。所以相比其他机器，他的YGC相对会频繁一点。大约10秒左右触发一次。而其他机器大概是1分钟触发一次。

STEP1

既然创建了这么多的socket相关对象。那需要看看是谁在不停的创建。这里可以使用开源的btrace或者其他instrument工具进行运行时监控(PS: 如果对于instrument和agent感兴趣的可以看此文如何开发一款java应用运行时的监控程序https://juejin.im/entry/5bd7f9156fb9a05d185f3a

最低0.47元/天 解锁文章
连接池：别让连接池帮了倒忙
Cr1556648487的博客
09-02 652
今天，我再与你说说另一种很重要的池化技术，即连接池。我先和你说说连接池的结构。连接池一般对外提供获得连接、归还连接的接口给客户端使用，并暴露最小空闲连接数、最大连接数等可配置参数，在内部则实现连接建立、连接心跳保持、连接管理、空闲连接回收、连接可用性检测等功能。连接池的结构示意图，如下所示：业务项目中经常会用到的连接池，主要是数据库连接池、Redis连接池和HTTP连接池。所以，今天我就以这三种连接池为例，和你聊聊使用和配置连接池容易出错的地方。
Redis 总结[安装、持久化、主从复制、哨兵、分片集群、内存淘汰策略、内存模型、缓存风险]
weixin_44266223的博客
03-07 4122
文章目录说明Redis 简介由来为什么Redis效率那么高Nosql数据库对比1.性能2.便利性3.存储空间4.可用性5.可靠性6.一致性各个Nosql数据库的优缺点1.Redis2.Memcache3.MongoDB安装Redis 3.01.安装所需依赖2.创建目录，下载或上传安装包3.解压4.编译安装5.启动持久化机制（AOF和RDB）1.什么是持久化2.AOF1.概述2.开启AOF持久化方式3.三种写入策略1.always2.everysec3. no4.AOF重写1.两种重写方式5.AOF文件损坏6
windows socket 泄漏相关补丁包.zip
07-31
# 使用说明 三个补丁具体使用方式见下文，选择一个安装即可。 ## 问题描述 当Windows2008R2系统运行时间超过497天，TCP/IP的网络资源（端口）就不会再自动释放，在运行一段时间后，本机的网络资源就会被全部用光。这样就会造成系统中任何需要网络资源的组件都无法正常工作，例如DNS，replication等。 故障现象如： 1. 同域控通信异常，表现为使用域用户登陆报‘同域控失去联系 2. 共享文件夹，外部ip用户无法访问 3. 域名解析失败 4. 如果该windows2008为桌面云关键组件如域控、controller、viewconnection，则将导致整个桌面云平台异常，用户登陆失败等问题。 ## 处理过程 1. 确认是否是该问题 - Windows事件日志中查看6013事件，计算当前操作系统运行时间是否超过497天 - Windows事件日志中重复报5719事件：RPC服务器不可用 2. 对运行时间超过497天的局点，先重启windows2008R2系统，恢复业务 3. 打上系统补丁，彻底解决此问题 - KB976932: 微软提供的hotfix补丁，目前官网已经下线，下载不到了 - KB2577795: 另一个可能导致该问题的补丁，解决系统socket泄露的问题 - KB976932: windows server 2008R2 的SP1更新包，涵盖了上述两个补丁，比较大，可在官网下载：https://www.microsoft.com/zh-CN/download/details.aspx?id=5842
确认是否有socket泄露
abc123098098的博客
03-05 252
问题定位步骤： 1、 用root帐户 遍历 /proc/进程ID/fd目录，如果该目录下文件数比较大（如果大于10，一般就属于socket泄漏），根据该进程ID，可以确认该进程ID所对应的名称。 2、 重启程序恢复服务，以便后续查找问题。 3、 strace 该程序并记录strace信息。strace –p 进程ID >>/tmp/stracelog.log...
JVM垃圾回收为何会被java.lang.ref.Finalizer拖累？
最新发布
程序员总部的博客
04-16 851
finalize()就像JVM里的定时炸弹，平时可能相安无事，但一旦爆炸就是大事故。现代Java开发中，我们有更多更好的选择来处理资源清理。下次当你忍不住想写finalize()时，不妨先问问自己：这个对象真的需要在死后做些什么吗？能不能用try-with-resources解决？记住，好的Java程序员不仅要会让代码跑起来，更要让代码跑得好。
socket泄露的问题
weixin_30902251的博客
10-18 818
在增加keepalive和libevent 超时后，仍然会几个月后出现lsof统计句柄过多的问题，如下图，红线圈定的是不定期出现的错误关闭流，时间点和server端日志（只看到accpet fd，没有导致正常关闭的可写事件，也就是被keepalive关闭了，而应用层没有close，所以泄露了socket？）一致。异常关闭发生在红色和黑色两个报文处。 时间问题，下来继续追 转载于:https:...
linux socket句柄泄露,socket句柄泄漏问题的定位： losf和strace的联合使用！
weixin_35315019的博客
05-15 1836
最近遇到一个socket句柄泄漏的问题， 我们来简要说说如何定位：1. 确定哪个进程在泄漏， 可以用命令 lsof -n|awk '{print $2}'| sort | uniq -c | sort -nr | head ，这个命令找的是打开句柄数目最多的进程， 多敲入几次， 就知道是那个进程在增长了。 而且累积到一定阶段， 泄漏的进程打开的句柄数会增长。 此步骤可以找到泄漏的进程号xx...
tcp socket文件句柄泄漏
Lv的程序人生
04-06 1万+
今天发现有台redis机器上出现socket个数告警，这是很奇怪的现象。因为一台redis服务器上就部署了几个redis实例，打开的端口应该是有限。 1、netstat显示的tcp连接数正常 netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}' TIME_WAIT
java连接access_记录一次Jedis连接池内存泄露
weixin_39770416的博客
12-02 306
原本在排查一个项目的GC问题，借用另一个工程的堆dump来对比一下 ，结果发现了不为人知的陈年老bug。本文关键词：Jedis连接池，对象池，Java，内存泄漏bug看起来很简单，从Map中get对象和put对象的时候key不一样private 可是用MAT (Memory Analyzer)分析堆内存时发现堆中有12万个对象池12万个对象池根据对象池中的_factory是redis.client...
jedis的hscan方法出现内存溢出问题
qq_30908729的博客
03-20 1048
jedis的hscan方法出现内存溢出问题 解决方法： 下面是我使用hscan方法错误的写法，使用了递归，数据大的时候导致java代码出现StackOverflow的内存溢出错误： public boolean hscan(int dbIndex,String key,int pageSize){ Map<String, Integer> mapList=new Has...
system_server socket 泄露
xiaolli的专栏
03-06 2012
system_server 报oom 02-13 21:19:00.236 1122 1138 E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: ActivityManager 02-13 21:19:00.236 1122 1138 E AndroidRuntime: java.lang.OutOfMemoryError:
jedis-2.9.0.jar及连接池分享
09-11
jedis-2.9.0.jar及连接池分享!有需求的可以直接下载.用于引入jedis
SOCKET句柄泄露带来的内存灾难
顺其自然~专栏
08-15 1928
前些时候游戏莫名其妙出现大量内存泄露，我感到很诧异，当然一般情况下游戏的内存管理是极其严苛的，出现如此大量的内存泄露到底是怎么回事？句柄滥用导致的内存泄露会多夸张呢，尤其SOCKET，在某些客户端系统下，短短5个小时可以吃掉5GB以上内存，有甚者达到6GB，并且进程内存查看非常完好，并无激增，那内存去哪了？看看我们的排错过程。1。...
hwui android,Android bug——hwui中fb socket泄露问题
weixin_29323977的博客
05-28 181
现象描述：在launcher的使用过程中，会发现系统越来越慢，内存越来越少，通过adb shell ps -t可以查看到当前launcher开启了几百上千个线程，这样就导致了系统越来越慢。分析：通过定位，发现在hwui中，当绘制带阴影的字体的时候，使用了renderScript，由于renderScript中绘制阴影时，会开启3-4个线程来处理阴影文字。void FontRenderer::blu...
socket fd泄露导致进程无法读写文件、进行网络请求问题的排查过程
txtang123的博客
09-13 1311
文章目录bug现象排查过程结论 bug现象 一个后台进程在跑了1000多分钟后，不再写日志，同时进程还有每分钟发送的一个网络请求，在服务端也没看到日志。 排查过程 首先怀疑是进程死锁了。于是ps aux查看进程id为12260，再通过gdb attach 12260到进程，发现并没有进程没有停止在lock函数。再用gdb在网络请求函数打断点，发现仍然是正常的每分钟执行一次curl请求，但是会报server connect failed错误。说明进程仍在正常执行，只是写日志和网络请求都是失败了。 因此怀疑是进
redis 2.4.2似乎有内存泄漏
hbwdzjr的专栏
12-22 1260
今天对比时发现，redis2.4.2似乎存在内存泄漏，同样场景下2.4.2版本内存不断增长最终吃了4G左右，而2.2.2版本只用了大约90M，这个差别太大了。 不过似乎没看到谁说2.4.2有内存的问题，难道会是个例？有测试环境的话倒想做个更精确的对比。
Linux服务器Socket资源泄露导致无法连接的问题
sunny05296的博客
03-30 3218
查看当前进程的堆使用情况： # jmap -histo:live 14416 | less  num     #instances         #bytes  class name ----------------------------------------------    1:        260861       29216432  java.net.SocksSocket
socket句柄泄漏问题的定位： losf和strace的联合使用！
热门推荐
认知 行动 坚持
02-25 1万+
最近遇到一个socket句柄泄漏的问题， 我们来简要说说如何定位：        1.  确定哪个进程在泄漏， 可以用命令 lsof -n|awk '{print $2}'| sort | uniq -c | sort -nr | head   ，这个命令找的是打开句柄数目最多的进程， 多敲入几次， 就知道是那个进程在增长了。 而且累积到一定阶段， 泄漏的进程打开的句柄数会增长。  此步骤可以找
异常连接导致的内存泄漏排查
weixin_30609331的博客
08-03 631
目录 异常连接导致的内存泄漏排查 背景 详细流程 使用windbg分析dump文件 使用wireshark抓包分析 完成端口和重叠IO 重叠I/O 完成端口 Reactor模型与Proact...
jediscluster遇到的坑
02-19
### JedisCluster 使用中常见问题与解决方法 #### 连接超时或失败 在高并发场景下，可能会遇到连接超时或失败的情况。这通常是因为JedisCluster默认的连接池配置不足以应对大量请求。 为了优化这个问题，可以通过调整`GenericObjectPoolConfig`来增加最大活动对象数(`maxTotal`)以及等待获取连接的最大时间(`maxWaitMillis`)： ```java GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); poolConfig.setMaxTotal(64); poolConfig.setMaxIdle(10); poolConfig.setMinIdle(5); poolConfig.setMaxWaitMillis(2000L); Set<HostAndPort> jedisClusterNodes = new HashSet<>(); jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7001)); // 添加其他节点... JedisCluster jc = new JedisCluster(jedisClusterNodes, poolConfig); ``` 上述设置能够有效缓解因资源不足而导致的服务不可达现象[^2]。 #### 节点信息更新延迟 由于JedisCluster会在本地缓存各个Redis实例的信息并维持相应的连接池，因此在网络状况不佳或者集群拓扑发生变化的时候可能出现旧的数据未及时刷新的问题。对于这种情况，建议适当缩短心跳检测的时间间隔以便更快感知到变化；另外也可以通过手动调用`refreshSlotsCache()`强制重新同步最新的槽位分配情况。 ```java jc.getConnectionHandler().getSlotCache().clear(); // 清除现有缓存 jc.refreshSlotsCache(); // 刷新slot映射表 ``` 此操作有助于保持客户端所持有的元数据始终处于最新状态从而减少错误发生几率[^1]。 #### 多键事务处理局限性 值得注意的是，在分布式环境下实现跨多个物理机器间的原子性操作是非常复杂且代价高昂的事情。鉴于这一点，Redis本身仅提供了针对单一服务器内部多条记录的同时修改能力——即所谓的MULTI/EXEC机制。一旦涉及到了不同主机之间的协调，则不再适用此类方式完成一致性保障的任务了[^5]。 如果应用程序确实存在这方面的需求，则需考虑采用诸如两阶段提交协议(Two-phase Commit Protocol)或者其他更高级别的补偿措施来弥补这一缺陷所带来的影响。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值