执行很快的SQL却导致慢接口

在解决慢SQL和慢接口时，发现有些SQL执行挺快的，但是接口呈现的结果就是时间过长。那么或许是数据库连接池配置不合理。如果并发线程数超过了连接数，那么就会有部分线程无法获得连接而进入阻塞，等待其他线程释放连接后才能访问数据库。由这个问题，我想到其实我们对系统内的堆内存以及CPU的使用情况缺乏很好的监控。很多时候，我们系统变慢或者系统崩溃跟这几块资源的使用情况息息相关，后续慢慢做好这方面的监控，对我们优化系统性能和定位系统问题会有很大的帮助。同时我也将这块的实战逐渐培养起来。

 

由此扩展下JVM垃圾回收知识点：

1、Minor GC：从年轻代（包括Eden、Survivor区）回收内存
（1）当JVM无法为一个新的对象分配内存的时候，越容易触发Minor GC。所以分配率越高，内存越来越少，越频繁执行Minor GC
（2）执行Minor GC操作的时候，不会影响到永久代（Tenured）。从永久代到年轻代的引用，被当成GC Roots，从年轻代到老年代的引用在标记阶段直接被忽略掉。

2、Major GC：清理整个老年代，当eden区内存不足时触发。
3、Full GC：清理整个堆空间，包括年轻代和老年代。当老年代内存不足时触发
     Full GC触发条件：
    （1）调用System.gc时，系统建议执行Full GC，但是不必然执行
    （2）老年代空间不足
    （3）方法区空间不足
    （4）通过Minor GC后进入老年代的平均大小大于老年代的可用内存
    （5）由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小