从产品出厂到部署，再到运营，期间各种疑难杂症，且看如何处理
1.应用卡顿问题
问题描述： 现场打开页面极为卡顿，打开一个页面需要10s以上
排查思路：卡顿问题可能由于多重问题引起，首先应排除环境问题，如网络卡顿延迟、网络不通等情况，环境问题排查之后，在考虑是否是代码问题。环境问题可以根据一次请求的各个方面耗时来判断，首先可通过浏览器控制台中请求的Timing来判断。Timing中的Content Dowload时间过长，判断为带宽过小。
问题定位：该服务器带宽过小，只有1M，导致网络传输过慢。
2.JSON栈溢出
问题描述：在一次处理测试问题单的时候，出现了一个奇怪的StackOverflow的报错，看到报错之时，很明显是JSON转字符串的时候，出现了死循环。
问题排查：简单查看之后，发现是对象DBDate对象引发。查看DBDate类以及其父类，并未发现有引用自身的行为或对象。深入跟踪FastJson源码发现，转换的过程中出现了非常多的DBNull字符串，是DBDate的父类，进去之后看属性也没有什么异常。然后尝试各种如transient等方法，均未生效。
问题定位：再次跟踪源码，发现转换过程中出现了很多没有的成员属性，进一步深入发现原因：FastJson在做转换时，与传统的如org.JSON或GSON等不同的是，会根据对象的getter方法进行判断，并且不会调用对象的toString方法。后看到FastJson的toJSONString方法中也可以定义一些特殊的配置来实现一些需要。回归问题本身，DBDate的父类DBNull中有个方法public DBNull getDBNull(){...}，FastJSON解析时候会将DBnull作为一个属性，DBNull中非常不规范的写法造成了对象的循环引用，导致了问题的发生。
3.间歇性卡顿
问题描述：近期，PMS平台间歇性卡顿，严重影响现场用户作业开票等工作。
问题排查：对于卡顿问题，除了2.1提到的带宽问题，需要排查服务响应时间是否很长。如果服务响应时间很长，首先要查看配置有无问题，现场环境需要按照优化手册上面配置相关内存等，有时候数据库查询慢也会导致卡顿问题。以上步骤之后，可以借助工具Java Visual VM，首先排查内存等信息。常见引起卡顿的原因是线程阻塞。
问题定位：经过跟踪Dump日志，发现频繁出现线程阻塞在Log4j日志输出上。基本定位问题，发送更新包，升级为logback，问题解决。
5 Nginx访问-502 Bad Gateway
问题描述：配置Nginx转发至80端口时，出现了大量的502Bad Gateway的报错。奇怪的是，随便选一个报错的Url，直接访问都是可以访问的，并且每次报错的资源文件都不相同，配置与现象见下图：
问题排查：公司测试服务器上面的配置项非常繁多，为了减少干扰，尝试使用全新的只有基础配置的Nginx配置文件，发现是同样的问题。尝试非80端口，发现不存在该问题。那么问题显然就是转为转发至80与非80端口的区别上面了。尝试寻找80端口和非80端口区别，在后台打印日志输出http请求头等对比，未发现异常，后查阅大量资料后发现，80端口会被默认识别成HTTP协议，而非80端口会被识别成TCP协议处理。
HTTP请求会默认自动释放连接，导致Nginx出现类似远程服务器关闭了连接这个报错。修改方案，将HTTP协议版本改为1.1，并将Connection置为空，HTTP1.1默认支持长连接，能够大幅提升效率，不用频繁建立连接。
问题定位：配置中加入proxy_http_version 1.1;proxy_set_header Connection '';强制使用HTTP1.1，问题解决。