zoukankan      html  css  js  c++  java
  • 记录面试遇到的几个自己不太熟悉的问题(1)

     一、mysql碎片

    二、内存溢出和泄露

    三、mysql预编译

    四、SQL执行顺序

    1.mysql碎片

      原来,在MySQL中,如果我们删除了表中的大量数据,或者我们对含有可变长度文本数据类型(VARCHAR,TEXT或BLOB)的表进行了很多更改,不过被删除的数据记录仍然被保持在MySQL的链接清单中,因此数据存储文件的大小并不会随着数据的删除而减小。

      当我们确定数据需要被清除掉时,那么这些数据就已经成了无用的数据,但是按照MySQL的处理方式,这些数据仍然会占用我们的磁盘空间,从而造成了极大的资源浪费。不仅如此,过大的数据文件还会导致MySQL执行相关数据操作时需要耗费更多的性能和时间。因此,对MySQL的某些数据表进行碎片整理是非常有必要的。

      对MySQL进行碎片整理的方法非常简单,因为MySQL已经给我们提供了对应的SQL指令,这个SQL指令就是OPTIMIZE TABLE,其完整语法如下:

    OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE table_name1 [, table_name2] ...

      从上面的语法描述中,我们可以得知,OPTIMIZE TABLE可以一次性对多个表进行碎片整理,只需要在OPTIMIZE TABLE后面接多个表名,并以英文逗号隔开即可。

      此外,OPTIMIZE TABLE语句有两个可选的关键字:LOCAL和NO_WRITE_TO_BINLOG。在默认情况下,OPTIMIZE TABLE语句将会被记录到二进制日志中,如果我们指定了LOCAL或NO_WRITE_TO_BINLOG关键字,则不会记录。当然,一般情况下,我们也无需关注这两个关键字。

     2.内存溢出和内存泄露

      内存泄漏定义(memory leak):一个不再被程序使用的对象或变量还在内存中占有存储空间。

           一次内存泄漏似乎不会有大的影响,但内存泄漏堆积后的后果就是内存溢出。
      内存溢出 out of memory :指程序申请内存时,没有足够的内存供申请者使用,或者说,给了你一块存储int类型数据的存储空间,但是你却存储long类型的数据,那么结果就是内存不够用,此时就会报错OOM,即所谓的内存溢出。 

    二者的关系:

    1. 内存泄漏的堆积最终会导致内存溢出
    2. 内存溢出就是你要的内存空间超过了系统实际分配给你的空间,此时系统相当于没法满足你的需求,就会报内存溢出的错误。
    3. 内存泄漏是指你向系统申请分配内存进行使用(new),可是使用完了以后却不归还(delete),结果你申请到的那块内存你自己也不能再访问(也许你把它的地址给弄丢了),而系统也不能再次将它分配给需要的程序。就相当于你租了个带钥匙的柜子,你存完东西之后把柜子锁上之后,把钥匙丢了或者没有将钥匙还回去,那么结果就是这个柜子将无法供给任何人使用,也无法被垃圾回收器回收,因为找不到他的任何信息。
    4. 内存溢出:一个盘子用尽各种方法只能装4个果子,你装了5个,结果掉倒地上不能吃了。这就是溢出。比方说栈,栈满时再做进栈必定产生空间溢出,叫上溢,栈空时再做退栈也产生空间溢出,称为下溢。就是分配的内存不足以放下数据项序列,称为内存溢出。说白了就是我承受不了那么多,那我就报错。

      由于java的JVM引入了垃圾回收机制,垃圾回收器会自动回收不再使用的对象,了解JVM回收机制的都知道JVM是使用引用计数法和可达性分析算法来判断对象是否是不再使用的对象,本质都是判断一个对象是否还被引用。那么对于这种情况下,由于代码的实现不同就会出现很多种内存泄漏问题(让JVM误以为此对象还在引用中,无法回收,造成内存泄漏)。

    1、静态集合类,如HashMap、LinkedList等等。如果这些容器为静态的,那么它们的生命周期与程序一致,则容器中的对象在程序结束之前将不能被释放,从而造成内存泄漏。简单而言,长生命周期的对象持有短生命周期对象的引用,尽管短生命周期的对象不再使用,但是因为长生命周期对象持有它的引用而导致不能被回收。

    2、各种连接,如数据库连接、网络连接和IO连接等。在对数据库进行操作的过程中,首先需要建立与数据库的连接,当不再使用时,需要调用close方法来释放与数据库的连接。只有连接被关闭后,垃圾回收器才会回收对应的对象。否则,如果在访问数据库的过程中,对Connection、Statement或ResultSet不显性地关闭,将会造成大量的对象无法被回收,从而引起内存泄漏。

    3、变量不合理的作用域。一般而言,一个变量的定义的作用范围大于其使用范围,很有可能会造成内存泄漏。另一方面,如果没有及时地把对象设置为null,很有可能导致内存泄漏的发生。

    public class UsingRandom {
        private String msg;
        public void receiveMsg(){
            readFromNet();// 从网络中接受数据保存到msg中
            saveDB();// 把msg保存到数据库中
        }
    }        

      如上面这个伪代码,通过readFromNet方法把接受的消息保存在变量msg中,然后调用saveDB方法把msg的内容保存到数据库中,此时msg已经就没用了,由于msg的生命周期与对象的生命周期相同,此时msg还不能回收,因此造成了内存泄漏。

      实际上这个msg变量可以放在receiveMsg方法内部,当方法使用完,那么msg的生命周期也就结束,此时就可以回收了。还有一种方法,在使用完msg后,把msg设置为null,这样垃圾回收器也会回收msg的内存空间。

    4、内部类持有外部类,如果一个外部类的实例对象的方法返回了一个内部类的实例对象,这个内部类对象被长期引用了,即使那个外部类实例对象不再被使用,但由于内部类持有外部类的实例对象,这个外部类对象将不会被垃圾回收,这也会造成内存泄露。

    5、改变哈希值,当一个对象被存储进HashSet集合中以后,就不能修改这个对象中的那些参与计算哈希值的字段了,否则,对象修改后的哈希值与最初存储进HashSet集合中时的哈希值就不同了,在这种情况下,即使在contains方法使用该对象的当前引用作为的参数去HashSet集合中检索对象,也将返回找不到对象的结果,这也会导致无法从HashSet集合中单独删除当前对象,造成内存泄露

    如何解决内存溢出?

      启动参数 -XX:+HeapDumpOnOutOfMemoryError

      如果发生内存泄露和内存溢出,就会在根目录上生成***.hprof文件

      通过内存分析工具Eclipse Memory Analysis Tools (MAT),就可以对内存进行分析 

      如果是内存泄露,可进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露对象是通过怎样的路径与GC   Roots相关联并导致垃圾收集器无法自动回收它们的。

      掌握了泄露对象的类型信息及GC Roots引用链的信息,就可以比较准确的定位出泄露代码的位置。

      如果不存在泄露,就是内存中的对象确实都还必须存活着,就应该检测虚拟机的堆参数(-Xmx和-Xms),与机器物理内存对比,看看是否可以调大,从代码上检查是否存在某些

      对象生命周期过长、持有状态时间过长的情况,尝试减少程序运行期的内存消耗。

    内存溢出的原因及解决方法:

    (1) 内存溢出原因:

    • 内存中加载的数据量过于庞大,如一次从数据库取出过多数据;
    • 集合类中有对对象的引用,使用完后未清空,使得JVM不能回收;
    • 代码中存在死循环或循环产生过多重复的对象实体;
    • 使用的第三方软件中的BUG;
    • 启动参数内存值设定的过小

    (2)内存溢出的解决方案:

    • 第一步,修改JVM启动参数,直接增加内存。(-Xms,-Xmx参数一定不要忘记加。)
    • 第二步,检查错误日志,查看“OutOfMemory”错误前是否有其 它异常或错误。
    • 第三步,对代码进行走查和分析,找出可能发生内存溢出的位置。

    重点排查以下几点:

    • 1.检查对数据库查询中,是否有一次获得全部数据的查询。一般来说,如果一次取十万条记录到内存,就可能引起内存溢出。这个问题比较隐蔽,在上线前,数据库中数据较少,不容易出问题,上线后,数据库中数据多了,一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
    • 2.检查代码中是否有死循环或递归调用。
    • 3.检查是否有大循环重复产生新对象实体。
    • 4.检查对数据库查询中,是否有一次获得全部数据的查询。一般来说,如果一次取十万条记录到内存,就可能引起内存溢出。这个问题比较隐蔽,在上线前,数据库中数据较少,不容易出问题,上线后,数据库中数据多了,一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
    • 5.检查List、MAP等集合对象是否有使用完后,未清除的问题。List、MAP等集合对象会始终存有对对象的引用,使得这些对象不能被GC回收。

    第四步,使用内存查看工具动态查看内存使用情况

     

    一个Java内存泄漏的排查案例

    确定频繁Full GC现象

    首先通过“虚拟机进程状况工具:jps”找出正在运行的虚拟机进程,最主要是找出这个进程在本地虚拟机的唯一ID(LVMID,Local Virtual Machine Identifier),因为在后面的排查过程中都是需要这个LVMID来确定要监控的是哪一个虚拟机进程。

    同时,对于本地虚拟机进程来说,LVMID与操作系统的进程ID(PID,Process Identifier)是一致的,使用Windows的任务管理器或Unix的ps命令也可以查询到虚拟机进程的LVMID。

    jps命令格式为:

      jps [ options ] [ hostid ]

    使用命令如下:

    使用jps:jps -l

    使用ps:ps aux | grep tomat找到你需要监控的ID(假设为20954),再利用“虚拟机统计信息监视工具:jstat”监视虚拟机各种运行状态信息。

    jstat命令格式为:

      jstat [ option vmid [interval[s|ms] [count]] ]

    使用命令如下:

      jstat -gcutil 20954 1000

    意思是每1000毫秒查询一次,一直查。gcutil的意思是已使用空间站总空间的百分比。

    分析方法通常有两种:

    1)把堆dump下来再用MAT等工具进行分析,但dump堆要花较长的时间,并且文件巨大,再从服务器上拖回本地导入工具,这个过程有些折腾,不到万不得已最好别这么干。

    2)更轻量级的在线分析,使用“Java内存影像工具:jmap”生成堆转储快照(一般称为headdump或dump文件)。

    • jmap命令格式:
    • jmap [ option ] vmid
    • 使用命令如下:
    • jmap -histo:live 20954

    查看存活的对象情况。

    定位到代码

    定位带代码,有很多种方法,比如前面提到的通过MAT查看Histogram即可找出是哪块代码。

     3.mybatis是如何实现预编译的

      mybatis 默认情况下,将对所有的 sql 进行预编译。mybatis底层使用PreparedStatement,过程是先将带有占位符(即”?”)的sql模板发送至mysql服务器,由服务器对此无参数的sql进行编译后,将编译结果缓存,然后直接执行带有真实参数的sql。核心是通过#{ } 实现的
    在预编译之前,#{ } 解析为一个 JDBC 预编译语句(prepared statement)的参数标记符?。

    //sqlMap 中如下的 sql 语句
    select * from user where name = #{name};
    //解析成为预编译语句
    select * from user where name = ?;

    如果${ },SQL 解析阶段将会进行变量替换。不能实现预编译。

    select * from user where name = '${name}'
    //传递的参数为 "ruhua" 时,解析为如下,然后发送数据库服务器进行编译。
    select * from user where name = "ruhua";

    4.SQL的执行顺序

    一、sql执行顺序 

    • (1)from 
    • (3) join 
    • (2) on 
    • (4) where 
    • (5)group by(开始使用select中的别名,后面的语句中都可以使用)
    • (6) avg,sum.... 
    • (7)having 
    • (8) select 
    • (9) distinct 
    • (10) order by 


    从这个顺序中我们不难发现,所有的 查询语句都是从from开始执行的,在执行过程中,每个步骤都会为下一个步骤生成一个虚拟表,这个虚拟表将作为下一个执行步骤的输入。 

    • 第一步:首先对from子句中的前两个表执行一个笛卡尔乘积,此时生成虚拟表 vt1(选择相对小的表做基础表) 
    • 第二步:接下来便是应用on筛选器,on 中的逻辑表达式将应用到 vt1 中的各个行,筛选出满足on逻辑表达式的行,生成虚拟表 vt2 
    • 第三步:如果是outer join 那么这一步就将添加外部行,left outer jion 就把左表在第二步中过滤的添加进来,如果是right outer join 那么就将右表在第二步中过滤掉的行添加进来,这样生成虚拟表 vt3 
    • 第四步:如果 from 子句中的表数目多余两个表,那么就将vt3和第三个表连接从而计算笛卡尔乘积,生成虚拟表,该过程就是一个重复1-3的步骤,最终得到一个新的虚拟表 vt3。 
    • 第五步:应用where筛选器,对上一步生产的虚拟表引用where筛选器,生成虚拟表vt4,在这有个比较重要的细节不得不说一下,对于包含outer join子句的查询,就有一个让人感到困惑的问题,到底在on筛选器还是用where筛选器指定逻辑表达式呢?on和where的最大区别在于,如果在on应用逻辑表达式那么在第三步outer join中还可以把移除的行再次添加回来,而where的移除的最终的。举个简单的例子,有一个学生表(班级,姓名)和一个成绩表(姓名,成绩),我现在需要返回一个x班级的全体同学的成绩,但是这个班级有几个学生缺考,也就是说在成绩表中没有记录。为了得到我们预期的结果我们就需要在on子句指定学生和成绩表的关系(学生.姓名=成绩.姓名)那么我们是否发现在执行第二步的时候,对于没有参加考试的学生记录就不会出现在vt2中,因为他们被on的逻辑表达式过滤掉了,但是我们用left outer join就可以把左表(学生)中没有参加考试的学生找回来,因为我们想返回的是x班级的所有学生,如果在on中应用学生.班级='x'的话,left outer join会把x班级的所有学生记录找回(感谢网友康钦谋__康钦苗的指正),所以只能在where筛选器中应用学生.班级='x' 因为它的过滤是最终的。 
    • 第六步:group by 子句将中的唯一的值组合成为一组,得到虚拟表vt5。如果应用了group by,那么后面的所有步骤都只能得到的vt5的列或者是聚合函数(count、sum、avg等)。原因在于最终的结果集中只为每个组包含一行。这一点请牢记。 
    • 第七步:应用cube或者rollup选项,为vt5生成超组,生成vt6. 
    • 第八步:应用having筛选器,生成vt7。having筛选器是第一个也是为唯一一个应用到已分组数据的筛选器。 
    • 第九步:处理select子句。将vt7中的在select中出现的列筛选出来。生成vt8. 
    • 第十步:应用distinct子句,vt8中移除相同的行,生成vt9。事实上如果应用了group by子句那么distinct是多余的,原因同样在于,分组的时候是将列中唯一的值分成一组,同时只为每一组返回一行记录,那么所以的记录都将是不相同的。 
    • 第十一步:应用order by子句。按照order_by_condition排序vt9,此时返回的一个游标,而不是虚拟表。sql是基于集合的理论的,集合不会预先对他的行排序,它只是成员的逻辑集合,成员的顺序是无关紧要的。对表进行排序的查询可以返回一个对象,这个对象包含特定的物理顺序的逻辑组织。这个对象就叫游标。正因为返回值是游标,那么使用order by 子句查询不能应用于表表达式。排序是很需要成本的,除非你必须要排序,否则最好不要指定order by,最后,在这一步中是第一个也是唯一一个可以使用select列表中别名的步骤。 
    • 第十二步:应用top选项。此时才返回结果给请求者即用户。 
    1.查询中用到的关键词主要包含六个,并且他们的顺序依次为 
      select--from--where--group by--having--order by 
      其中select和from是必须的,其他关键词是可选的,这六个关键词的执行顺序 
      与sql语句的书写顺序并不是一样的,而是按照下面的顺序来执行 
    • from--where--group by--having--select--order by, 
    • from:需要从哪个数据表检索数据 
    • where:过滤表中数据的条件 
    • group by:如何将上面过滤出的数据分组 
    • having:对上面已经分组的数据进行过滤的条件  
    • select:查看结果集中的哪个列,或列的计算结果 
    • order by :按照什么样的顺序来查看返回的数据 
    2.from后面的表关联,是自右向左解析的 
      而where条件的解析顺序是自下而上的。 
      也就是说,在写SQL文的时候,尽量把数据量大的表放在最右边来进行关联, 
      而把能筛选出大量数据的条件放在where语句的最下面。

     SQL Select语句完整的执行顺序【从DBMS使用者角度】: 
      1、from子句组装来自不同数据源的数据; 
      2、where子句基于指定的条件对记录行进行筛选; 
      3、group by子句将数据划分为多个分组; 
      4、使用聚集函数进行计算; 
      5、使用having子句筛选分组; 
      6、计算所有的表达式; 
      7、使用order by对结果集进行排序。 

    from 子句--执行顺序为从后往前、从右到左
    表名(最后面的那个表名为驱动表,执行顺序为从后往前, 所以数据量较少的表尽量放后)

    where子句--执行顺序为自下而上、从右到左

     

    group by--执行顺序从左往右分组

    提高GROUP BY 语句的效率, 可以通过将不需要的记录在GROUP BY 之前过滤掉。即在GROUP BY前使用WHERE来过虑,而尽量避免GROUP BY后再HAVING过滤。

    having 子句----很耗资源,尽量少用

    避免使用HAVING 子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作.

    如果能通过Where 子句在GROUP BY前限制记录的数目,那就能减少这方面的开销.

    on、where、having 这三个都可以加条件的子句中,on 是最先执行,where 次之,having 最后,因为on 是先把不符合条件的记录过滤后才进行统计,它就可以减少中间运算要处理的数据,按理说应该速度是最快的。

    select子句--少用*号,尽量取字段名称

    order by子句--执行顺序为从左到右排序,很耗资源

     

    参考:MYSQL优化之碎片整理

    参考:什么是内存溢出以及java中内存泄漏5种情况的总结

    参考:SQL预编译
  • 相关阅读:
    React38路由守卫的实现和使用以及Route的不同渲染方式解析
    React37嵌套路由及路由重定向
    React36react-router的路由传参取参
    ElasticSearch总结3-聚合
    ElasticSearch总结2-高级搜索
    [转]Druid连接池泄露引发的血案!
    Swagger的Starter使用及增强
    MySQL问题排查
    ElasticSearch总结1-查询表达式
    使用Spring Validation优雅地进行参数校验
  • 原文地址:https://www.cnblogs.com/heqiyoujing/p/11696687.html
Copyright © 2011-2022 走看看