java面试题总结5

锁的优化策略
1.读写分离，锁分离
2.减少锁持有时间，可以减少其他的锁的持有时间
3.以正确的顺序获得和释放锁
4.适当的锁的范围扩大或者缩小，控制锁的粒度

Spring Bean中作用域
singleton：单例模式，在整个Spring IoC容器中，使用singleton定义的Bean将只有一个实例。
prototype：原型模式，每次通过容器的getBean方法获取prototype定义的Bean时，都将产生一个新的Bean实例。
request：对于每次HTTP请求，使用request定义的Bean都将产生一个新实例，即每次HTTP请求将会产生不同的Bean实例。只有在Web应用中使用Spring时，该作用域才有效。
session：对于每次HTTP Session，使用session定义的Bean都将产生一个新实例。同样只有在Web应用中使用Spring时，该作用域才有效。
Global session：每个全局的HTTP Session，使用session定义的Bean都将产生一个新实例。典型情况下，仅在使用portlet context的时候有效。同样只有在Web应用中使用Spring时，该作用域才有效。

java中启定时任务
1.利用sleep特性//休眠
2.time和timerTask//定时器
3.ScheduledExecutorService service.scheduleAtFixedRate(runnable, 10, 1, TimeUnit.SECONDS);
//任务调度服务

操作系统如何进行分页调度
用户程序的地址空间被划分成若干固定大小的区域，称为“页”，相应地，内存空间分成若干个物理块，页和块的大小相等。可将用户程序的任一页放在内存的任一块中，实现了离散分配。

linux内核的三种主要调度策略：
1，SCHED_OTHER 分时调度策略，
2，SCHED_FIFO实时调度策略，先到先服务
3，SCHED_RR实时调度策略，时间片轮转

TCP和UDP相关
TCP通过什么方式提供可靠性:
1.超时重发，发出报文段要是没有收到及时的确认，会重发。
2.数据包的校验，也就是校验首部数据和。
3.对失序的数据重新排序
4.进行流量控制，防止缓冲区溢出
5.快重传和快恢复
6.TCP会将数据截断为合理的长度

TCP和UDP的区别:
1.UDP是无连接的，TCP必须三次握手建立连接
2.UDP是面向报文，没有拥塞控制，所以速度快，适合多媒体通信要求，比如及时聊天，支持一对一，一队多。多对一，多对多。
3.TCP只能是一对一的可靠性传输
TCP的RPC，在协议栈的下层，能够灵活的对字段进行定制，减少网络传输字节数，降低网络开销，提高性能，实现更大的吞吐量和并发数。但是实现代价高，底层复杂，难以得到开源社区的支持，难以实现跨平台

集群调优
1.load
load是被定义为特定时间间隔内运行队列中的平均线程数，uptime查看，一般load不大于3，我们认为负载是正常的，如果每个CPU的线程数大于5，表示负载就非常高了。
2.CPU利用率
查看cpu的消耗的情况命令：top | grep Cpu
查看磁盘的剩余空间命令：df -h
查看系统的内存的使用情况：free -m

心跳检测方法
1.使用ping命令
对于full gc导致不响应，网络攻击这种 ping展示不明确
2.使用curl
访问我们的自测地址
3.对不同的功能使用curl检测，在response中加入状态头，表示正常

可以计算qps通过28原则
innodb存储引擎通过预写事务日志的方式保障事务的原子性，也就是在写入数据之前，先将数据操作写入日志，这种成为预写日志
轻量级锁认为在程序运行过程中，绝大部分的锁，在整个同步周期内都是不存在竞争的，利用cas操作避免互斥开销。
偏向锁是jdk1.6中引入的一项优化，甚至可以省掉CAS操作，偏向锁偏向第一个获得他锁的线程，如果在接下来执行过程中，这个锁没有被其他线程获取，则持有偏向锁的线程永远不需要同步。

GC调优
查看GC日志，根据GC日志来优化
我们可以通过jps找到我们虚拟机正在运行的进程。参数 通过jps -help了解。
Jstat -gc 或者 -gcutil 查看堆使用情况-class 配合Jps得到进程
BTrace原理利用hotspot虚拟中的热替换，把代码动态的替换到java程序内，可在不需要重启的时候就可以排除问题

JConsole
我们也可以使用JConsole来分析这是一个图形化的，比较容易让我们操作
使用VisualVM 进行远程连接 使用JMX方式，也有修改tomcat的catalina就行了

内部类去访问外部变量，为什么需要加final?
题目有点问题，并不是所有的外部变量才加final,我们的内部类访问我们的成员变量就不需要加final,但是访问局部变量就必须要加final，因为方法（main方法）结束我们栈帧也就销毁了，但是我们内部类在堆中并没有被销毁，如果引用了成员变量，这时候被销毁了肯定是不行的，所以我们就需要成员变量设置为final，让其在方法（main方法）结束时不会被销毁。

泛型
泛型的作用:在我们没有泛型的时候，我们通过对Object的引用来对参数的任意化，任意化有个缺点就是要做显示的强制类型转换，强制转换有一个不好的地方是运行的时候才会报错，泛型的好处实在编译的时候检查类型安全，所以泛型的特点就是简单安全，泛型的原理是类型擦除，java的泛型是伪泛型，在编译期间，所有的泛型信息都会被擦除掉。在生成的java字节码中是不包含泛型中的类型信息的。使用泛型的时候加上的类型参数，会在编译器编译的时候去掉。比如List信息在编译后都是List。

nginx和apache的对比
1.nginx相对于apache来说
（1）轻量级占用的内存少；
（2）抗并发,nginx是异步非阻塞，apache是阻塞的，在高并发的情况下，nginx的性能优；
（3）高度模块化的设计，编写模块相对简单；
（4）社区活跃，各种高性能模块有。
适合场景：apache适合于动态的请求，而负载均衡和静态请求适合nginx，nginx采用的是epoll，并且有自己的一套sendfile系统，减少在内存中的赋值次数。
2.apache 相对于nginx 的优点：
（1）rewrite ，比nginx 的rewrite 强大 ；
（2）模块超多，基本想到的都可以找到 ；
（3）少bug ，nginx 的bug 相对较多 ；
（4）超稳定 。

线程、进程的共享和独立
共享的部分：
1.进程代码段
2.进程的公有数据(利用这些共享的数据，线程很容易的实现相互之间的通讯)
3.进程打开的文件描述符、
4.信号的处理器、
5.进程的当前目录
6.进程用户ID与进程组ID
线程独有的内容包括：
1.线程ID
2.寄存器组的值
3.线程的堆栈
4.错误返回码
5.线程的信号屏蔽码

最大的优势就是线程极高的执行效率。因为子程序切换不是线程切换，而是由程序自身控制，因此，没有线程切换的开销，和多线程比，线程数量越多，线程的性能优势就越明显。
第二大优势就是不需要多线程的锁机制，因为只有一个线程，也不存在同时写变量冲突，在线程中控制共享资源不加锁，只需要判断状态就好了，所以执行效率比多线程高很多。

简单的说一下nginx的优点
1.作为高性能的web服务器:相比Apache,Nginx使用更少的资源，支持更多的并发连接，体现更高的效率，这点让Nginx受到虚拟主机提供商的欢迎。一个Nginx实例能够轻松支持高达5万并发。
2.作为负载均衡服务器:Nginx即可以在内部直接支持PHP，也可以支持作为HTTP代理服务器对外进行服务，独有的send files系统，减少文件复制次数。
3.作为邮件代理服务器:也比Apache好很多。
4.Nginx安装简单，配置文件非常简洁。启动容易，7*24小时几乎不间断，可以进行热更新。

BIO
在BIO中读和写都是同步阻塞的，阻塞的时间取决于对方I/O线程的处理速度和网络的传输速度。本质上来讲，我们是无法保证生产环境的网络状况和对端的应用程序可以足够快，应用程序是不应该依赖对方的处理速度，它的可靠性就非常差。BIO就算用线程池实现，要是所有可用线程都被阻塞到故障点中，后续的所有I/O消息都将在队列中排队。
NIO
（1）提供了高速，面向块的I/O。
（2）在NIO中所有数据都是用缓冲区来处理的，也就是使用我们的jvm中的direct memory（直接内存）。缓冲区是一个数组，但是缓冲区不仅仅是一个数组，缓冲区提供了对数据的结构化访问以及维护读写位置等信息。
（3）在NIO中channel（通道）也是特别重要的他是我们数据读写的通道，一般来说流比如inputStream和outputStream都是单向的，而通道是双向的，是全双工的。
（4）多路复用器Selector也是比较重要的，掌握它对于我们的NIO编程来说是比较重要的。多路复用器提供选择已经就绪的任务的能力。Selector会不断轮训注册在其上的Channel,如果某个Channel上面发生读或者写事件，这个Channel就处于就绪状态，会被Selector轮询出来，通过Selection Key可以获取就绪Channel的集合，进行后续的I/o操作。我们只需要一个线程就可以管理我们多个客户端。

垃圾收集器
1.Serial收集器
Serial收集器是JAVA虚拟机中最基本、历史最悠久的收集器，在JDK 1.3.1之前是JAVA虚拟机新生代收集的唯一选择。Serial收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅是说明它只会使用一个 CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。
Serial收集器到JDK1.7为止，它依然是JAVA虚拟机运行在Client模式下的默认新生代收集器。它也有着优于其他收集器的地方：简单而高 效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集 效率。在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很大，收集几十兆甚至一两百兆的新生代（仅仅是新生代使用的内存，桌面应用基本上不会 再大了），停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不是频繁发生，这点停顿是可以接受的。所以，Serial收集器对于运行在 Client模式下的虚拟机来说是一个很好的选择。
2. Parallel（并行）收集器
这是 JVM 的缺省收集器。就像它的名字，其最大的优点是使用多个线程来通过扫描并压缩堆。串行收集器在GC时会停止其他所有工作线程（stop-the- world），CPU利用率是最高的，所以适用于要求高吞吐量（throughput）的应用，但停顿时间（pause time）会比较长，所以对web应用来说就不适合，因为这意味着用户等待时间会加长。而并行收集器可以理解是多线程串行收集，在串行收集基础上采用多线 程方式进行GC，很好的弥补了串行收集的不足，可以大幅缩短停顿时间（如下图表示的停顿时长高度，并发比并行要短），因此对于空间不大的区域（如 young generation），采用并行收集器停顿时间很短，回收效率高，适合高频率执行。
3.CMS收集器
CMS（Concurrent Mark Sweep）收集器是基于“标记-清除”算法实现的，它使用多线程的算法去扫描堆（标记）并对发现的未使用的对象进行回收（清除）。整个过程分为6个步骤，包括：
初始标记（CMS initial mark）

并发标记（CMS concurrent mark）
并发预清理（CMS-concurrent-preclean）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）
并发重置（CMS-concurrent-reset）
其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一 般会比初始标记阶段稍长一些，但远比并发标记的时间短。其他动作都是并发的。
需要注意的是，CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序的运行自然还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次 收集中处理掉它们，只好留待下一次GC时再将其清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，即还需要预留足够的 内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使 用。在默认设置下，CMS收集器在老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数 -XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数以获取更好的性能。要是CMS运行期 间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置 得太高将会很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。
try catch有return 在字节码中 可以看到会出现Goto跳转行数，跳转到finally中的return