OutOfMemoryError本地线程不足问题分析

java.lang.OutOfMemoryError本地线程不足问题

    11月份中旬客户方的一个系统突然报内存异常，当时是早上上班的时候碰到该项目的项目经理，还跟该项目的项目经理开玩笑说你们系统上线将近8个月都没问题了，应该不会出现
    系统故障等问题了吧，谁知刚说完，没半小时该项目经理突然给我打电话说，生产系统出现故障了，没办法使用了，原因为明。让我赶紧去客户方机房一起分析问题。
   
       于是顾不上吃早餐，赶紧跑过去机房帮忙分析是什么故障问题。过去的时候发现客户方的领导以及公司的项目经理和几位开发人员以及合作公司的几位开发人员和领导也在那边围观在那边研究问题原因，看这架势问题估计很严重，不然怎么也会把合作公司的技术总监也叫上了。过去一听原委，原来系统有四个实例其中一个实例宕机，其他三个实例处于半死不活状态，也没办法正常运作，前端客户打电话反映没办法登录，或者登录进去打开页面都是异常信息等。我也很积极的投入他们围观中，一起分析问题发现后台日志一直刷屏似地的显示各种异常信息，看得眼花缭乱。
       看了半天才看出一点眉目原来内存溢出，GC日志分析发现一直做大GC，而且还是做system.gc。客户方说明看能否尽快解决，而且客户方那边有规定，没有特殊情况下不能随意重启机器。
       就是说白天在使用过程中，出现问题除非有修改东西之类的才能去重启机器，不能先重启让客户方立马使用，但是根据他们说，如果重启后不用一小时还是出现同样问题， 因为交易量很大，后台并发很多，程序代码有问题是肯定有的，不然不会出现此问题。一时半会儿我也定位不出哪里出问题，也不清楚怎么解决，看了日志问题，我也茫然了，犹豫了一会儿，我只能跟客户方说临时解决应急方案倒是有一个，但是不能只能治本不能治根，确保白天能正常使用，但是晚上凌晨还是要重启来缓解第二天的正常使用，至于能否完全解决，你们只能过会儿把日志文件等取过来我在静心分析下才能知道原因点。于是我就提供了修改方案，无非就是JVM配置问题新生代重新划分，而且禁用system。gc功能，然后客户方重启机器。就这样连续两天过去了，生产可以正常使用，但是后台还是时不时的报错，经过这两天的日志分析以及生产监控，发现主要问题是本地线程创建异常，其实就是线程使用不足引起的。根本原因是框架平台代码问题，修改此问题对系统的功能影响面很大，而且这个平台不是我们公司的是客户方买的一个平台，这意味着此问题没办法解决。思量了一天，说白了出事故后这两天，搞得我晚上都没办法睡觉，虽然可以说我可以不管这件事情，因为我只是测试人员，主要工作是做好部门管理，但是这毕竟我们公司的项目（虽然结项了），现在是我之前公司接了该项目，他们公司也派了开发人员和他们的技术总监参与分析解决问题，我们公司好歹也表个态比较以前也是我们做的项目，虽然接这个项目到结项没问题，但是突然在交接后立马出问题，也不能说是谁的问题，其实是平台的问题，两家公司都没责任，但是问题没人解决，这样也不好，大家都分析了两三天也没得出结论，而生产只是客户方暂时借用我的应急方案顶住，但是反映不是很好。
      
       苦恼了，三天后，也让客户方查看了各自资源的分配情况，线程开启数量，内存使用情况等各种内存占用计算分析，两天都在加班在本子上鬼画符似的计算各自内存分配。
       最终给出了三个解决方案。增加系统线程数thread_max ，被客户方否决原因说要重启系统风险更大，那就降低线程栈的大小吧，客户方回应默认就行，修改这个数值风险太大。
       深受打击，最后我只好说，既然两项不行，那就把-XMX从1200M，改为1024m吧，反正你们最多也是只能用到900M，好吧这种解决方案风险最低。修改最方便。被采纳了，改为1001M，修改后重启了。其实在跟客户方提供解决方案沟通期间，还很费劲的解释了，JAVA NEW一个线程引发的后期血案等等，说明了线程创建后什么时候会占用系统内存、对内存，是谁占用怎么占用等等一大堆原理，才被采纳。其实我也是半吊子不是很懂，但是都是围绕了此问题，进行解释，才说服他们。就这样过了三周了，到现在貌似没出现任务错误，也看了，客户方前台操作响应很快，应该没问题了。希望不要在出问题了，记得今年四月份上线，出了问题，也是搞得我头昏脑胀的，那时不是数据库表分区，就是建索引要么改SQL实现方式，要么要修改应用代码设计，还要改各自参数配置，整个项目的人员一起忙得不亦乐乎，最终问题是解决，但是竟然还没顶住8个月又出问题了，这次我算是迷糊中解决了，但是下次在出现，不知道会是什么情况，只能拭目以待了，应该说下次出现了，不关我事了，这个项目交接给我之前的老东家了。