好久没分享工作总结啦，今天来一份代码优化总结。用模板方法+策略+工厂方法模式优化了代码，耐心点看完，应该对大家有帮助的~ 先来了解一下类似的业务场景，简言之，就是：多个商户接入我们系统，都是走一个类似的流程通过http请求出去的。 我的优化代码思路，是有重复代码，先把它抽出来，…

为了解决问题，我们必须从 JDK 的引用谈起。 每种编程语言都有自己操作内存中元素的方式，例如在 C 和 C++ 里是通过指针，而在 Java 中则是通过“引用”。 在 Java 中一切都被视为了对象，但是我们操作的标识符实际上是对象的一个引用（reference）。 “每种编…

这一次重启真的无法解决问题了：一次 MySQL 主动关闭，导致服务出现大量 CLOSE_WAIT 的全流程排查过程。 近日遇到一个线上服务 socket 资源被不断打满的情况。通过各种工具分析线上问题,定位到问题代码。这里对该问题发现、修复过程进行一下复盘总结。 先看两张图。一…

线上故障主要会包括 CPU、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如 jstack、jmap 等工具也是不囿于一个方面的问题的，基本上出问题就是 df、free、top 三连，然后依次 jstack、j…

之前或多或少分享过一些内存模型、对象创建之类的内容，其实大部分人看完都是懵懵懂懂，也不知道这些的实际意义。 线程执行一个任务迟迟没有返回，应用假死。 接口响应缓慢，甚至请求超时。 CPU 高负载运行。 这类问题并不像一个空指针、数组越界这样明显好查，这时就需要刚才提到的内存模型…

由于之前的日志里是不会打印这些消息日志的，所以，我猜测是不是日志级别设置错了。而且这个消息打印的类并不在项目源码里，而是依赖的jar包中，问题大概是知道了，应该是日志依赖jar包冲突了。 因为系统是线上运行的，所以知道某个类里采用哪个日志框架和使用何种日志级别都是个问题！不过，…

通常处理线上问题的三板斧是重启-回滚-扩容，能够快速有效的解决问题，但是根据我多年的线上经验，这三个操作略微有些简单粗暴，解决问题的概率也非常随机，并不总是有效。这边总结下通常我处理应用中遇到的故障的解决方案。 每一层都有可能出现问题，越底层出现问题，影响面越大。所以每一个层次…

对性能不佳的ArkServer进行了改造和重写。重编发布一段时间后，结果发现新发布的Svr的机器内存一直在上涨。如下图示：观察后，第一反应是完了，一定存在内存泄露。花了3、4天时间，使用各种办法进行定

说起线上故障，程序员应该都经历过，从故障处理恢复过程中我们能快速提高。踩坑多了，慢慢也就成了大牛。这道题也是大厂的面试官们特别喜欢问的问题之一，从候选人对这道题的回答过程中，面试官至少能获取到两个方面的反馈。第一是你平时负责的项目是不是核心项目，如果你说你负责的是后管系统，出了…