APNS开源包的内存泄露问题

APNS(全称：Apple Push Notification Service），主要是用于往苹果设备推送push消息通知！

基本流程：

今天要聊的问题集中在第4个环节，我们自己的服务器往苹果的消息中心推送通知。

现状：

历史原因，push的代码散落在各个应用中，随着新消息通道不断接入，开发、维护成本较高，开始考虑构建push中心，

封装dubbo接口对外提供服务，对外屏蔽各种差异，将所有的push业务逐步收扰到push中心。

过程漫长，开始接入的是个人业务，每天的调用量不大，服务器还表现正常；

8月底，BI的推送管理后台开始对接进来并发布上线，由于BI是针对各种营销活动批量推送的，一次任务少则几万，多则上千万，

此时服务器开始暴露一些问题。

下面开始介绍优化过程：

1）第一次线上问题暴露，现象：短信报警，查看dubbo注册中心无provider服务，登录线上机器，load飙高到了40，ps看了jvm进程在，但dubbo日志里，服务注册失败。

查看gc，一直触发Full gc，old空间却释放不了

解决：重启集群。之前的策略是发送过来的数据会封装到一个线程任务里，由ThreadPoolExecutor慢慢消化，怀疑一次发送的token过多（一次400），生产速度快于消费速度，导致对象积累。联系BI的稀土同学，将一次任务的数量调整为100，并且每次调用接口后休眠100ms。

2）另外查看了jvm的参数，修改启动脚本，将原来的堆大小由1G调整为2G，新生代由原来的300M调整为1G

-Xms2g -Xmx2g -Xmn1g -XX:+UseParallelOldGC

了解BI的机器配置，24核cpu 64G内存，配置很高但只有一台，采用的是dubbo默认的随机路由方式，1对多，担心负载不均衡，

注：线上dubbo注册中心观察过，并不是所有的机器同时宕机，而是一个逐步的过程

调整路由策略，改为轮询方式：

更多内容可以参考