JDDTechTalk的博客

是极致魅惑、洒脱自由的？是知性柔情、温婉大气的？是纯真无邪、活泼可爱的Metaspace？如果以上不是你的菜，那还有……刁蛮任性，无迹可寻的CodeCache！性感火辣、心思细腻的高贵冷艳，独爱你一人的OOM Killer！总有一款，能让你钟情！BUG 选择权，现在交由你手！

系统是一个定时任务系统，需要定时执行业务代码，业务代码主要是访问MYSQL数据库和缓存进行操作，该开始启动，系统日志一切正常，但是运行一段时间到凌晨后，系统就自动崩溃了，java进程没有了，只留下了程序崩溃日志

回过头来咱们再分析以下这个功能，通过系统日志及监控，发现该功能商家日常使用较少，并且大部分商家的保质期商品较少，极少数会存在有非常多保质期商品数据的情况。但是一旦出现这样的问题就会很致命，所以在导出功能设计之初我们就应该考虑到将来任何可能出现的情况，并做好提前的预防。另外就是要做功能的限制，例如导出次数、导出数据量的限制功能来保障商家体验及系统的安全稳定。另外再说一下，对导出功能的理解，对于商家而已，导出需求是正常的。但是过多大批量数据的一起导出无论对哪个系统来说都是非常危险的一个功能。

最近有用户反馈测试环境Java服务总在凌晨00:00左右挂掉，用户反馈Java服务没有定时任务，也没有流量突增的情况，Jvm配置也合理，莫名其妙就挂了

在压测的中，对于问题的根因尽最大能力探索挖掘，不断沉淀总结实践经验。尤其是一些开源的组件使用，要详细学习了解使用规范以及最佳实践，必要时可以加入性能测试，确保满足我们质量和性能要求。

1.流程图：跨数据中心同步数据单channel管道同步数据能力不足，导致tcp环阻塞。从而导致netty eventLoop的消费WriteTask任务(WriteAndFlush)中的write能力大于flush能力，因此申请的大量的直接内存存放在ChannelOutboundBuffer#unflushedEntry链表中没法flush。

在应用中，我们使用的 SpringData ES的 ElasticsearchRestTemplate来做查询，使用方式不对，导致每次ES查询时都新实例化了一个查询对象，会加载相关类到元数据中。最终长时间运行后元数据出现内存溢出；

路由计算服务是路由系统的核心服务，负责运单路由计划的计算以及实操与计划的匹配。在运维过程中，发现在长期不重启的情况下，有TP99缓慢爬坡的现象。此外，在每周例行调度的试算过程中，能明显看到内存的上涨。

我方有一应用，偶尔会出现GC时间过长（间隔约4小时），导致性能波动的问题(接口最长需要耗时3秒以上)。经排查为G1垃圾回收器参数配置不当 叠加 MySQL 链接超过闲置时间回收，产生大量的虚引用，导致G1在执行老年代混合GC，标记阶段耗时过长导致。以下为对此问题的分析及问题总结。