关于系统卡顿,jvm崩溃的场景原因汇总
sql语句
在sql层面,如果缺乏优化意识,一量数据量上涨或者是并发上涨到一定知识,必然会导致jvm崩溃或者是线程被占满。
- 数据量大,没有索引,全表扫描(前期开发时、设计表结构时,未考虑索引创建)
- 索引失效或者未命中
- 数据量小
- 数据量大,非精确过滤
- sql索引字段使用了如函数、计算、or、like +前%、not....
- 索引太多、设计不合理,导致数据库发神经,无法命中高效索引
- 过滤条件太多,每个条件过滤结果都不精确,导致数据被多次过滤检索,cpu消耗大
- 多表关联时,关联字段没有使用外键索引,或者是关联条件复杂且使用了函数计算
- 表里存在大字段,未对大字段做特殊处理,每次查询都将大字段数据查询出来加载到内存中,但又并未使用。
- sql编写太过复杂,随意使用了特殊函数。应该从设计时考虑,前端做必要的多次请求(请求非常快)和缓存、后端也需要做必要的缓存机制、多线程处理、分多次请求(也需要控制次数)
- 针对上述情况,最根本的建表时是否合理,创建索引是否合理,必要情况可以使用函数索引。
后端程序
- jvm 崩溃
- 参数没有调优
- 将全表数据查询出来,加载到内存中
- 原因:1、一些没有分页的列表查询,过滤条件没有做非空判断。2、有过滤条件,但是过滤后,仍然返回了大量的数据,并且存在大量循环情况。
- 存在多次循环调用接口或者数据库请求的情况,当并发上去后,线程被占满,资源无法释放。(适当采用多线程,建议使用响应式异步编程)
- 大量使用了数据库事务及代码同步锁,容易引起交叉事务,进而导致锁表发生,数据库事务无法释放。
- 数据库连接,文件流等未做规范的关闭处理,一旦出现异常,连接无法关闭,导致资源不足,引起系统崩溃。
- 接口请求的http连接,没有设置超时时间,一旦接口提供方存在异常,http连接一直处于请求状态中,积累一定量后,也会引起应用资源不足的情况。
前端程序
- 接口请求使用了同步方法,如果接口请求时间较长,自然就会直接表现出系统卡顿现象。
- 对于高步的操作,未做点击的屏蔽事件,即一次请求还未完全响应,用户可以重复点击请求。这对后端来说,非常容易引起高并发现象。高并发自然会引起非常多的问题,所以前端必须注意控制接口的请求频次。
- 静态资源为做压缩,或者文件数量多,用户量一旦上去,也容易产生高并发,对服务器的线程数、网络流量也有不小的压力。