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
代码语言：javascript复制-Xms2g -Xmx2g -Xmn1g -XX: UseParallelOldG了解BI的机器配置，24核cpu 64G内存，配置很高但只有一台，采用的是dubbo默认的随机路由方式，1对多，担心负载不均衡，
注：线上dubbo注册中心观察过，并不是所有的机器同时宕机，而是一个逐步的过程
调整路由策略，改为轮询方式。
更多内容可以参考 dubbo的开发手册
代码语言：javascript复制<dubbo:reference id="***" interface="******" loadbalance="roundrobin" 3）这次持续的时间长了点，不过在任务跑了4个小时后，系统的old区占用到70%多，开始担心一会Full GC是否会正常回收。
由于采用的是UseParallelOldGC 并行回收方式（适用于吞吐量大应用类型），不象CMS可以设置空间使用比例主动触发回收。
但我们可以通过dump内存快照方式手动触发一次Full GC
代码语言：javascript复制jmap -dump:live,format=b,file=heap.bin <pid>
很不幸，Full GC 清理一次后 old区依然有 68% ，可以肯定，发生内存泄露
开始安装mat插件，分析内存快照，具体可参考《MAT使用教程》
发现有大量的SSLSocketImpl实例对象无法回收，整个链路占了heap 50%
4） 这个问题比较棘手，因为我们使用的是一个外部开源框架；
只能网上先查查资料，看看有没有其他人遇到过类似问题；
很不幸没有找到现成答案，幸运的是在github上找到了源代码。
https://github.com/fernandospr/javapns-jdk16
不过也只有代码，并没有过多文档介绍，不过这不重要
自己动手，丰衣足食。
分析代码，发现两处疑点：
a）NotificationThreads 里面会根据预传的线程数量，创建n个线程，每个线程负责往一定数量设备发送消息，主线程为了收集n个线程的最终发送结果，NotificationThreads继承了ThreadGroup，并将对象实例传到每个子线程构造器中，对主线程wait，当所有的子线程执行完毕后，通过notifyAll唤醒所有进程，继续后面的流程。
貌似没有什么明显问题，但是mat的分析结果ThreadGroup里面有大量其它线程，担心会有干扰。决定采用一种更靠谱更安全的方式，通过CountDownLatch来控制。
b）在子任务结束后（无论是正常结束还是非正常结束），在finally里面进行后续操作，关闭socket连接；
另外 对 countDownLatch数量减1
重新打包并上传maven仓库（注意：需要修改pom配置文件）
代码语言：javascript复制<dependency>
<groupId>com.github.fernandospr</groupId>
<artifactId>javapns-jdk16</artifactId>
<version>2.3.1-SNAPSHOT</version>
</dependency>本地运行单元测试，可以成功推送消息
c）线上集群部署了一台机器，开始beta测试，运行一个1200W的推送任务
经过258次YGC后，年老代的空间使用率 依然很低，只有2%
另外观察S0、S1、E发现，一次YGC后 to交换区基本能满足存放存活对象，不会有大量对象晋升到old区。
任务跑完后，gc情况，YGC 602次，没有触发Full GC
另外性能监控显示已经发送了800多万 条消息（注：图中统计的是接口调用次数，每次接口调用传100个用户token），响应时间正常。
总结：
a）线上报警，无论load彪的有多高，又或cpu使用率100%，千万不要慌，先保留一台问题机器，其它的机器全部重启，保证不影响外部使用
b）要从整个链路全面分析问题，多和身边的同事沟通讨论，也许会碰撞出灵感。
