1.Interrupted
2.什么叫异常
3.Spring Boot引起的中a中制“堆外内存泄漏”排查及经验总结
4.简述 Stop-The-World 的实现原理
5.java中throw和throws的区别

Interrupted

       中断异常是Java中一个关键的概念，理解它对于编写稳定且可靠的断源断机代码至关重要。当一个函数声明了会抛出InterruptedException，中a中制执行时就可能引发中断异常。断源断机常见的中a中制会抛出此异常的函数包括涉及阻塞操作的函数。中断异常主要用于处理轻量级阻塞的断源断机同程app源码情况，例如线程在等待或定时等待时。中a中制重量级阻塞，断源断机即同步代码块中的中a中制线程状态为blocked，是断源断机无法被中断的。

       线程的中a中制状态迁移从NEW状态开始，通过调用start()函数进入RUNNABLE或READY状态。断源断机在没有进行阻塞的中a中制情况下，线程主要在RUNNABLE和READY状态之间切换，断源断机这种切换由操作系统自动完成。中a中制当调用阻塞函数时，线程状态转变为WAITING或TIMED_WAITING，前者是无限期阻塞，后者则限制了阻塞的时间。若使用了synchronized关键字或块，线程状态则变为BLOCKED。

       阻塞与唤醒的函数中，LockSupport.park()/unpark()对至关重要，它们是Concurrent包中实现Lock的关键操作原语。中断异常实际上意味着唤醒轻量级阻塞状态的线程，而非直接中断线程。淘宝客的源码

       在判断线程是否收到中断信号时，thread.interrupted()和thread.isInterrupted()有细微差别。前者发送唤醒信号并可能引发InterruptedException，后者不仅读取中断状态，还能重置中断标志位。

       强制终止线程可能导致资源泄露，Java提供了stop()和destory()方法，但它们不建议使用，因为可能导致不可预料的行为。守护线程与非守护线程的主要区别在于，当所有非守护线程退出时，整个JVM进程将退出；而守护线程不会影响JVM的退出。在开发中，通过设置标志位来停止循环线程是一种常见的做法。

什么叫异常

       é—®é¢˜ä¸€ï¼šJAVA什么是异常 异常通常指，你的代码可能在编译时没有错误，可是运行时会出现异常。比如常见的空指针异常。也可能是程序可能出现无法预料的异常，比如你要从一个文件读信息，可这个文件不存在，程序无法运行下去了，故程序要顶这些异常，通过异常处理机制来抛出这些异常，程序员就可以通过抛出的异常来修改代码。try{ }catch{ }finally{ }try块中放入可能会出现异常的代码，catch块负责捕获异常，finally块负责处理一些必须执行的代码，比较关闭流等。

        问题二：什么叫异常 品质异常，是指产品在正常作业状态下，产生出异于平常产品的产品或状态。

        问题三：异常是什么意思 不正常，超出正常的

        问题四：什么叫品质异常 品质异常通俗点：即品质状况不正常具体点：品质异常指企业生产中未按作业手法，流程，运用合理的设备和环境所产出的产品超出其正常值而出现的一个结果它的造成因素有人为，设备，环境，方法。即操作人员不认真，设备故障，环境变化，方法不当。它的出现将导致企业产品不能更好的推捎给客户，从而降低的企业信誉和企业利益，是企业生存的头等大事它的改善方法有以下几个步聚：计划分析，计划执行，检查审理，再次改善即：对异常出现的状况进行方案探讨得出实行方案进行执行改善。根据改善的状况进行品质对比，如欠缺则需再次制定改善方案来引导

        问题五：什么叫做qq异常操作 提示的异常信息包括以下几种：

        1、QQ号码的帐户余额被异常查询；

        2、QQ号码被举报异常发送垃圾及骚扰短信；

        3、QQ号码异常登录；

        4、QQ游戏帐号异常登录；

        5、在异常情况下删除好友。

        注：当发现不是您自己操作，可对号码进行锁定、申请密码保护等保护操作。

        问题六：Java中的异常的捕获和抛出是什么意思，有什么区别 抛出异常是方法中声明该方法可能出现的异常状态(利用throws关键字)

        捕获异常是在已知方法中会产生（或不完全确定，但是可能会产生）异常的情况下，对能产生异常的代码部分进行的try catch处理

        假设方法A 声明的时候有声明抛出异常 void A() throws IOException

        那么在方法B中如果要调用A 只有2中策略可以

        1：B不处理，继续抛出，交给下一个环节处理

        2：B捕获他，并处理

        void B(){ try { A(); }catch(IOException e) { 这里进行异常的处理，如果不想处理，不写任何代码也可以，但是不推荐 }}

        问题七：什么叫数据解析异常？？？ 就是数据不可以解析，可能是你哪里的设置问题

        问题八：什么叫异常考勤 迟到、早退、上班未打卡，下班未打卡、请假、旷工等，

        问题九：什么叫java异常，一直没有理解。 你在编写程序的时候，会考虑到很多情况，比如出现A情况怎么办，出现B情况怎么办，但不管你的思想有多么缜密，总有一些情况你是无法考虑到的，或者它本身就是不可预知的，就好比你考虑到了你的程序所有代码都安全了，但没考虑到联网的绩候，有个客户端给你发送了一个不合法的地址，从而造成程序不能处理，从而崩溃；又或者你需要访问数据库读取一条记录，本身就会面临记录不存在，或者有其他程序正在修改，从而锁定这条记录的情况。

        面对这种种你想不到或者有可能出错的行为的时候，就要用到异常。Java的异常就是提示你来处理这些各种你没想到却出现的情况，或者那些有问题的操作，从而完善的程序――因为如果不用解决的话，上面提到的这些操作会立刻被JVM中断，但程序会因为情况无法处理而中断，也就是崩溃了。

        抛出异常，意思就是JVM在通过异常机制取得了这些意外情况的具体信息之后，把这些信息以一个异常的形式反馈给你，意思是“这里出现了意想之外的情况”。而你要做的，就是根据异常的具体提示信息，判断到底是哪里出现了问题，进行有针对的修改。

        简而言之，异常是JVM对程序的一个保护机制，也是程序员用来调试程序的最可靠手段。

        问题十：DNF中异常状态是指什么状态？ 异常状态主要分为以下几种类型

        僵直性异常状态：睡眠、冰冻、石化、眩晕

        持续掉血性异常状态：中毒、感电、出血、灼伤

        降低属性（降BUFF）性异常状态：减速（降低移动速度属性）、破甲（降低防御属性）、诅咒（降低四维属性）

        其它特殊性异常状态：束缚、混乱、失明

        职业和怪物特有的技能所触发的异常状态：金身的忏悔之锤所触发的忏悔状态、魔道的舒露露和召唤的大小骑士和影舞者的分身等所触发的仇恨状态、恐怖之阿斯特罗斯的血饮十字架所触发的渐停息状态，兰蒂卢斯的鹰犬BOSS房间的吼女和蠕动的魔格尼斯等所触发的精神控制状态等。

        睡眠：一段时间内无法操作，进入躺地状态。

        冰冻：一段时间内无法操作，队友可以击碎冰块。

        石化：一段时间内无法操作，且最后会给予对方无属性爆炸伤害。

        眩晕：一段时间内无法操作，这是真正意义上的长时间僵直。

        中毒：一段时间内受到持续性伤害。

        感电：一段时间内，每隔一定时间受到光属性伤害。

        灼伤：一段时间内受到持续性火属性伤害。

        束缚：一段时间内无法移动。

        混乱：一段时间内，所有产生命令的方向移动均按照反方向移动，比如在已经配置好的键盘设置中，所按的方向键是右键，而人物却移动到左边。

        失明：一段时间内，

Spring Boot引起的“堆外内存泄漏”排查及经验总结

       为了更好地实现对项目的管理，我们将组内一个项目迁移到MDP框架（基于Spring Boot），随后我们就发现系统会频繁报出Swap区域使用量过高的异常。笔者被叫去帮忙查看原因，发现配置了4G堆内内存，但是实际使用的物理内存竟然高达7G，确实不正常。JVM参数配置是“-XX:MetaspaceSize=M -XX:MaxMetaspaceSize=M -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=m -XX:InitialCodeCacheSize=m, -Xssk -Xmx4g -Xms4g,-XX:+UseG1GC -XX:G1HeapRegionSize=4M”，实际使用的物理内存如下图所示：

       使用Java层面的工具定位内存区域（堆内内存、Code区域或者使用unsafe.allocateMemory和DirectByteBuffer申请的堆外内存）。

       笔者在项目中添加-XX:NativeMemoryTracking=detailJVM参数重启项目，kdj指标公式源码使用命令jcmd pid VM.native_memory detail查看到的内存分布如下：

       发现命令显示的committed的内存小于物理内存，因为jcmd命令显示的内存包含堆内内存、Code区域、通过unsafe.allocateMemory和DirectByteBuffer申请的内存，但是不包含其他Native Code（C代码）申请的堆外内存。所以猜测是使用Native Code申请内存所导致的问题。

       为了防止误判，笔者使用了pmap查看内存分布，发现大量的M的地址；而这些地址空间不在jcmd命令所给出的地址空间里面，基本上就断定就是这些M的内存所导致。

       使用系统层面的工具定位堆外内存。

       因为已经基本上确定是Native Code所引起，而Java层面的工具不便于排查此类问题，只能使用系统层面的工具去定位问题。

       首先，使用了gperftools去定位问题。

       从上图可以看出：使用malloc申请的的内存最高到3G之后就释放了，之后始终维持在M-M。笔者第一反应是：难道Native Code中没有使用malloc申请，直接使用mmap/brk申请的？（gperftools原理就使用动态链接的方式替换了操作系统默认的内存分配器（glibc）。）

       然后，使用strace去追踪系统调用。

       因为使用gperftools没有追踪到这些内存，于是直接使用命令“strace -f -e"brk,mmap,munmap" -p pid”追踪向OS申请内存请求，但是订单管理系统源码并没有发现有可疑内存申请。

       接着，使用GDB去dump可疑内存。

       因为使用strace没有追踪到可疑内存申请；于是想着看看内存中的情况。就是直接使用命令gdp -pid pid进入GDB之后，然后使用命令dump memory mem.bin startAddress endAddressdump内存，其中startAddress和endAddress可以从/proc/pid/smaps中查找。然后使用strings mem.bin查看dump的内容，如下：

       从内容上来看，像是解压后的JAR包信息。读取JAR包信息应该是在项目启动的时候，那么在项目启动之后使用strace作用就不是很大了。所以应该在项目启动的时候使用strace，而不是启动完成之后。

       再次，项目启动时使用strace去追踪系统调用。

       项目启动使用strace追踪系统调用，发现确实申请了很多M的内存空间，截图如下：

       使用该mmap申请的地址空间在pmap对应如下：

       最后，使用jstack去查看对应的线程。

       因为strace命令中已经显示申请内存的线程ID。直接使用命令jstack pid去查看线程栈，找到对应的线程栈（注意进制和进制转换）如下：

       这里基本上就可以看出问题来了：MCC（美团统一配置中心）使用了Reflections进行扫包，底层使用了Spring Boot去加载JAR。因为解压JAR使用Inflater类，需要用到堆外内存，his源码然后使用Btrace去追踪这个类，栈如下：

       然后查看使用MCC的地方，发现没有配置扫包路径，默认是扫描所有的包。于是修改代码，配置扫包路径，发布上线后内存问题解决。

       为什么堆外内存没有释放掉呢？

       虽然问题已经解决了，但是有几个疑问。带着疑问，直接看了一下 Spring Boot Loader那一块的源码。发现Spring Boot对Java JDK的InflaterInputStream进行了包装并且使用了Inflater，而Inflater本身用于解压JAR包的需要用到堆外内存。而包装之后的类ZipInflaterInputStream没有释放Inflater持有的堆外内存。于是以为找到了原因，立马向Spring Boot社区反馈了这个bug。但是反馈之后，就发现Inflater这个对象本身实现了finalize方法，在这个方法中有调用释放堆外内存的逻辑。也就是说Spring Boot依赖于GC释放堆外内存。

       使用jmap查看堆内对象时，发现已经基本上没有Inflater这个对象了。于是就怀疑GC的时候，没有调用finalize。带着这样的怀疑，把Inflater进行包装在Spring Boot Loader里面替换成自己包装的Inflater，在finalize进行打点监控，结果finalize方法确实被调用了。于是又去看了Inflater对应的C代码，发现初始化的使用了malloc申请内存，end的时候也调用了free去释放内存。

       此时，怀疑free的时候没有真正释放内存，便把Spring Boot包装的InflaterInputStream替换成Java JDK自带的，发现替换之后，内存问题也得以解决了。

       再次看gperftools的内存分布情况，发现使用Spring Boot时，内存使用一直在增加，突然某个点内存使用下降了好多（使用量直接由3G降为M左右）。这个点应该就是GC引起的，内存应该释放了，但是在操作系统层面并没有看到内存变化，那是不是没有释放到操作系统，被内存分配器持有了呢？

       继续探究，发现系统默认的内存分配器（glibc 2.版本）和使用gperftools内存地址分布差别很明显，2.5G地址使用smaps发现它是属于Native Stack。内存地址分布如下：

       到此，基本上可以确定是内存分配器在捣鬼；搜索了一下glibc M，发现glibc从2.开始对每个线程引入内存池（位机器大小就是M内存），原文如下：

       按照文中所说去修改MALLOC_ARENA_MAX环境变量，发现没什么效果。查看tcmalloc（gperftools使用的内存分配器）也使用了内存池方式。

       为了验证是内存池搞的鬼，就简单写个不带内存池的内存分配器。使用命令gcc zjbmalloc.c -fPIC -shared -o zjbmalloc.so生成动态库，然后使用export LD_PRELOAD=zjbmalloc.so替换掉glibc的内存分配器。其中代码Demo如下：

       通过在自定义分配器当中埋点可以发现实际申请的堆外内存始终在M-M之间，gperftools监控显示内存使用量也是在M-M左右。但是从操作系统角度来看进程占用的内存差别很大（这里只是监控堆外内存）。

       使用不同分配器进行不同程度的扫包，占用的内存如下：

       为什么自定义的malloc申请M，最终占用的物理内存在1.7G呢？因为自定义内存分配器采用的是mmap分配内存，mmap分配内存按需向上取整到整数个页，所以存在着巨大的空间浪费。通过监控发现最终申请的页面数目在k个左右，那实际上向系统申请的内存等于k * 4k（pagesize） = 2G。

       为什么这个数据大于1.7G呢？因为操作系统采取的是延迟分配的方式，通过mmap向系统申请内存的时候，系统仅仅返回内存地址并没有分配真实的物理内存。只有在真正使用的时候，系统产生一个缺页中断，然后再分配实际的物理Page。

       整个内存分配的流程如上图所示。MCC扫包的默认配置是扫描所有的JAR包。在扫描包的时候，Spring Boot不会主动去释放堆外内存，导致在扫描阶段，堆外内存占用量一直持续飙升。当发生GC的时候，Spring Boot依赖于finalize机制去释放了堆外内存；但是glibc为了性能考虑，并没有真正把内存归返到操作系统，而是留下来放入内存池了，导致应用层以为发生了“内存泄漏”。所以修改MCC的配置路径为特定的JAR包，问题解决。在发表这篇文章时，发现Spring Boot的最新版本（2.0.5.RELEASE）已经做了修改，在ZipInflaterInputStream主动释放了堆外内存不再依赖GC；所以Spring Boot升级到最新版本，这个问题也可以得到解决。

简述 Stop-The-World 的实现原理

       简述 Stop-The-World 的实现原理

       Stop-The-World，简称 STW，是指在执行垃圾回收的过程中，冻结所有用户线程运行，直至垃圾回收线程执行完成。用户线程如何阻塞？这涉及一个概念。

       为什么要 Stop-The-World？目前主流虚拟机采用的都是可达性算法，算法核心是利用根对象作为起始点，根据对象之间的引用关系，即引用链，通过遍历引用链判断对象是否存活。可达性分析算法要求全过程基于一致性快照，即必须全程冻结用户线程运行。

       必须冻结用户线程的原因，是为了避免并发执行可能导致的两个问题。SafePoint 是一个安全点，可以理解为用户线程执行过程中的特殊位置。SafePoint 保存了当前线程的上下文，当线程执行到这些位置时，可以安全阻塞。

       因此，只有用户线程处于 SafePoint 时，才能安全阻塞。这意味着所有用户线程需要处于 SafePoint。SafePoint 插入到代码的某些位置，当线程运行到 SafePoint 代码时，会主动检查是否需要进入 SafePoint，这个主动检查过程称为 Polling。

       SafePoint 的位置包括所有非计数循环的末尾、所有方法返回之前以及每条 Java 编译后的字节码的边界。SafePoint 数量不宜过多或过少，以平衡进入 SafePoint 的前置时间和性能损耗。

       实现 Stop-The-World 需要所有用户线程处于 SafePoint。有两种方法：抢占式中断和主动式中断。抢占式中断由 JVM 中断所有线程，检查每个线程中断位置是否为 Safepoint。主动式中断则由用户线程主动轮询标志位，当标志位就绪，线程自行中断。

       针对用户线程各种状态的处理：正在执行字节码时，解释器检查用户线程标志，调用阻塞方法；正在运行 native 代码时，VM 线程发现后直接阻塞线程；运行 JIT 编译好的代码时，设置内存页不可读，线程发现不可读时被阻塞；处于阻塞状态时，线程一直阻塞直至进入 SafePoint；处于线程切换状态时，轮询状态直到线程阻塞。

       优化 STW：优化所有用户线程进入 SafePoint 的前置时间，加快垃圾回收线程执行，是进一步的优化方向。通过减少进入 SafePoint 的前置时间，可以更快开始执行垃圾回收线程。

java中throw和throws的区别

       æ¥¼ä¸»æ‚¨å¥½

       å€Ÿç”¨ç­”案

       è¿™ä¸¤è€…虽然看起来只有一个s的区别，但是作用完全不一样

       /////java处理异常方式///////////////////////////////

       åœ¨java代码中如果发生异常的话，jvm会抛出异常对象，导致程序代码中断，这个时候jvm在做的操作就是：创建异常对象，然后抛出，比如：

       int i= 1；

       int j = 0；

       int res = 0；

       res = i/j；//除0错误

       System.out.println(res);

       è¿™5句代码运行到第四句会中断，因为jvm抛出了异常

       ////throw的作用/////////////////////////////////////////

       æ‰‹åŠ¨æŠ›å‡ºå¼‚常

       ä½†æ˜¯æœ‰æ—¶å€™æœ‰äº›é”™è¯¯åœ¨jvm看来不是错误，比如说

       int age = 0;

       age = -;

       System.out.println(age);

       å¾ˆæ­£å¸¸çš„整形变量赋值，但是在我们眼中看来就不正常，谁的年龄会是负的呢。

       æ‰€ä»¥æˆ‘们需要自己手动引发异常，这就是throw的作用

       int age = 0;

       age = -;

       if(age<0)

       {

       Exception e = new Exception();//创建异常对象

       throw e;//抛出异常

       }

       System.out.println(age);

       ////throws的作用///////////////////////////////////

       å£°æ˜Žæ–¹æ³•å¯èƒ½å›žé¿çš„异常

       æœ‰å¼‚常被抛出了，就要做处理，所以java中有try-catch

       å¯æ˜¯æœ‰æ—¶å€™ä¸€ä¸ªæ–¹æ³•ä¸­äº§ç”Ÿäº†å¼‚常，但是不知道该怎么处理它，那么就放着不管，当有异常抛出时会中断该方法，而异常被抛到这个方法的调用者那里。这个有点像下属处理不了的问题就交到上司手里一样，这种情况称为回避异常

       ä½†æ˜¯è¿™ä½¿å¾—调用这个方法就有了危险，因为谁也不知道这个方法什么时候会丢一个什么样的异常给调用者，所以在定义方法时，就需要在方法头部分使用throws来声明这个方法可能回避的异常

       void fun()throws IOException,SQLException

       {

       ...

       }

       è¿™è¡¨ç¤º fun方法可能会丢两个异常出来，那么在调用fun的时候就会做好准备，比如可以这样

       try

       {

       fun();

       }catch(IOException e)

       {

       }catch(SQLException e)

       {

       }