Java中高级面试题总览(一)（2）

InputStream类的read()方法是从流里面取出一个字节，他的函数原型是 int read(); 
Reader类的read()方法则是从流里面取出一个字符（一个char），他的函数原型也是 int read(); 

package com.javapapers.java;
public class JavaIntegerCache {
    public static void main(String... strings) {
        Integer integer1 = 3;
        Integer integer2 = 3;
        if (integer1 == integer2)
            System.out.println("integer1 == integer2");
        else
            System.out.println("integer1 != integer2");
        Integer integer3 = 300;
        Integer integer4 = 300;
        if (integer3 == integer4)
            System.out.println("integer3 == integer4");
        else
            System.out.println("integer3 != integer4");
    }
}

至于是堆内存溢出还是方法区内存溢出还是栈内存溢出，其实可以用一些工具比如
JConsole来监视

内存溢出分析
JAVA dump查看线程运行情况:
=====查看栈信息=======================
1.查询java程序pid 
  netstat -ntpl | grep 8080
2.使用jstack [-l] 进程pid > xxx.log将进程里所有线程信息输入到指定文件中
  1)如果程序正常运行：使用jstack [-l] 进程pid > xxx.log将所有线程信息输入到指定文件中 
  2)如果程序无响应：使用 jstack -F [-m] [-l] 进程pid >xxx.log强制打印栈信息 
=====查看堆信息=======================
3.使用top命令找出占用cpu高（或者执行时间很长）的进程pid 
4.使用top -H -p 线程pid 找出占用cpu高（或执行时间长）的线程pid 
5.将占用cpu高的线程pid转换成16进制（window自带计算器） 
6.dump该进程的内存
  jmap -dump:format=b,file=文件名 [进程pid]   将转换后的pid在开始输出的dump文件（xxx.log）中搜索对应线程信息 
7.eclipse Memory Analyzer 对dump文件分析

volatile关键字禁止指令重排序(内存栅栏)有两层意思
1）当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对
后面的操作可见；在其后面的操作肯定还没有进行；
2）在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语
句放到其前面执行。
Happen-Before 原则
1. 程序次序原则：一个线程内，按照程序代码顺序，书写在前面的操作先发生于书写在后面的操作。 
2. volatile 规则：volatile 变量的写，先发生于读，这保证了 volatile 变量的可见性。 
3. 锁规则：解锁（unlock） 必然发生在随后的加锁（lock）前。 
4. 传递性：A先于B，B先于C，那么A必然先于C。 
5. 线程的 start 方法先于他的每一个动作。 
6. 线程的所有操作先于线程的终结。 
7. 线程的中断（interrupt（））先于被中断的代码。 
8. 对象的构造函数，结束先于 finalize 方法。

JVM将类加载过程分为三个步骤：装载（Load），链接（Link）和初始化(Initialize)
链接又分为三个步骤
验证：确保被加载类的正确性；
准备：为类的静态变量分配内存，并将其初始化为默认值；
解析：把类中的符号引用转换为直接引用；
加载过程中会先检查类是否被已加载，检查顺序是自底向上，从Custom ClassLoader到BootStrap 
ClassLoader逐层检查，只要某个classloader已加载就视为已加载此类，保证此类只所有ClassLoader加载一
次。而加载的顺序是自顶向下，也就是由上层来逐层尝试加载此类。
1）Bootstrap ClassLoader
负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类
2）Extension ClassLoader
负责加载java平台中扩展功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar或-Djava.ext.dirs指定目录下
的jar包
3）App ClassLoader
负责记载classpath中指定的jar包及目录中class
4）Custom ClassLoader
属于应用程序根据自身需要自定义的ClassLoader，如tomcat、jboss都会根据j2ee规范自行实现ClassLoader

-Xms512m 
-Xmx512m 
-XX:MetaspaceSize=256m 
-XX:MaxMetaspaceSize=256m 
-Xmn256m 
-XX:MaxDirectMemorySize=1g 
-XX:SurvivorRatio=10 
-XX:+UseConcMarkSweepGC 
-XX:CMSMaxAbortablePrecleanTime=5000 
##垃圾回收会清理持久代，移除不再使用的classes,只有在 UseConcMarkSweepGC  也启用的情况下才有用
-XX:+CMSClassUnloadingEnabled 
##使用cms作为垃圾回收使用80％后开始CMS收集
-XX:CMSInitiatingOccupancyFraction=80 
##使用手动定义初始化定义开始CMS收集
-XX:+UseCMSInitiatingOccupancyOnly 
##使用并发的方式执行FGC
-XX:+ExplicitGCInvokesConcurrent 
## 设置并行垃圾回收的线程数。此值可以设置与机器处理器数量相等
-XX:ParallelGCThreads=4 
-Xloggc:$work_dir/logs/gc.log 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=$work_dir/logs/java.hprof

Cms是以获取最短回收停顿时间为目标的收集器。基于标记-清除算法实现。比较占用cpu资源，切易造成碎片。
G1是面向服务端的垃圾收集器，是jdk9默认的收集器，基于标记-整理算法实现。可利用多核、多cpu，保留分
代，实现可预测停顿，可控。 

-server 
-Xms512m 
-Xmx512m 
-Xss1024K
-XX:PermSize=256m 
-XX:MaxPermSize=512m 
-XX:MaxTenuringThreshold=20 
-XX:CMSInitiatingOccupancyFraction=80 
-XX:+UseCMSInitiatingOccupancyOnly。
##设置JVM最大可用内存为3550M。
-Xmx3550m
#设置JVM初始内存为3550m,可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xms3550m
#设置每个线程的堆栈大小。在相同物理内 存下，减小这个值能生成更多的线程。但是操作系统对一
#个进程内的线程数还是有限制的，不能无限生成，
#经验值在3000~5000左右
-Xss128k 
#设置持久代大小为16m
-XX:MaxPermSize=16m
#设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直
#接进入年老代。对于年老代比较多的应用，可以提高效率。
#如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活
#时间，增加在年轻代即被回收的概论。
-XX:MaxTenuringThreshold=0

1）JRE中的Java基础包
2）Web应用WEB-INF\lib下的包
3）Tomcat\lib下的包

tx:advice，aop:config

1. 用户向服务器发送请求，请求被Spring 前端控制Servelt DispatcherServlet捕获；
2. DispatcherServlet对请求URL进行解析，得到请求资源标识符（URI）。然后根据该URI，调用HandlerMapping获得该Handler配置的所有相关的对象（包括Handler对象以及Handler对象对应的拦截器），最后以HandlerExecutionChain对象的形式返回；
3. DispatcherServlet 根据获得的Handler，选择一个合适的HandlerAdapter。（附注：如果成功获得HandlerAdapter后，此时将开始执行拦截器的preHandler(...)方法）
4.  提取Request中的模型数据，填充Handler入参，开始执行Handler（Controller)。 在填充Handler的入参过程中，根据你的配置，Spring将帮你做一些额外的工作：
      HttpMessageConveter： 将请求消息（如Json、xml等数据）转换成一个对象，将对象转换为指定的响应信息
      数据转换：对请求消息进行数据转换。如String转换成Integer、Double等
      数据根式化：对请求消息进行数据格式化。 如将字符串转换成格式化数字或格式化日期等
      数据验证： 验证数据的有效性（长度、格式等），验证结果存储到BindingResult或Error中
5.  Handler执行完成后，向DispatcherServlet 返回一个ModelAndView对象；
6.  根据返回的ModelAndView，选择一个适合的ViewResolver（必须是已经注册到Spring容器中的ViewResolver)返回给DispatcherServlet ；
7. ViewResolver 结合Model和View，来渲染视图

1.BIO（blocking IO）：同步阻塞 I/O
2.NIO（nonblocking IO）：同步非阻塞 I/O
3.多路复用IO（ IO multiplexing）
4.信号驱动I/O（ signal driven IO）
5.异步 I/O（asynchronous IO）

输出test文件的后五行：
liyi@liyi:~/Desktop > tail -n 5 test
输出test文件的前五行：
liyi@liyi:~/Desktop > head -n 5 test

　　总结来说，Lock和synchronized有以下几点不同：
　　1）Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；
　　2）synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异
常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放
锁；
　　3）Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直
等待下去，不能够响应中断；
　　4）通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。
　　5）Lock可以提高多个线程进行读操作的效率。
　　在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时
竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

Executors.newCachedThreadPool()：无限线程池。
Executors.newFixedThreadPool(nThreads)：创建固定大小的线程池。
Executors.newSingleThreadExecutor()：创建单个线程的线程池。
1.ExecutorService threadPool = Executors.newCachedThreadPool();  
SynchronousQueue是一个没有数据缓冲的BlockingQueue，生产者线程对其的插入操作put必须等待消费者的移
除操作take。所以newCachedThreadPool实际项目一般也很少运用
2.ExecutorService executor = Executors.newFixedThreadPool(3); 
这个线程池的队列LinkedBlockingQueue没有指定默认大小,高并发环境下
在对内存压力很大,所以生产环境一般都不使用这个

shutdown() 执行后停止接受新任务，会把队列的任务执行完毕。
shutdownNow() 也是停止接受新任务，但会中断所有的任务，将线程池状态变为 stop。

基于redis分布式限流超时时间设为1s

singleton : bean在每个Spring ioc 容器中只有一个实例。
prototype：一个bean的定义可以有多个实例。
request：每次http请求都会创建一个bean，该作用域仅在基于web的Spring ApplicationContext情形下有效。