Java面试总结

◆java中实现线程锁有哪些，实现原理是什么？

1、采用Synchronized关键字，实现原理是同步代码块是使用monitorenter和monitorexit指令实现的，同步方法（在这看不出来需要看JVM底层实现）依靠的是方法修饰符上的ACC_SYNCHRONIZED实现，jdk1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销，参考：http://www.importnew.com/23511.html

2、Concurrent包的同步类，例如ReentrantLock、AutomicInteger等：java层面通过继承AQS，然后配合unsafe提供的CAS操作以及链表这个数据结构，去实现乐观锁，互斥，共享，自旋等锁，当需要阻塞线程的时候，通过unsafe类调用操作系统的mutex互斥锁去实现阻塞，参考：https://www.cnblogs.com/diegodu/p/7998337.html

◆synchronized是如何保证有序性的（synchronized同步原理）
JVM规范规定JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。代码块同步是使用monitorenter和monitorexit指令实现，而方法同步是使用另外一种方式实现的，细节在JVM规范里并没有详细说明，但是方法的同步同样可以使用这两个指令来实现。

    monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处，JVM要保证每个monitorenter必须有对应的monitorexit与之配对。任何对象都有一个monitor与之关联，当且一个monitor 被持有后，它将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor的所有权，即尝试获得对象的锁。

    当使用synchronized关键字是，只能有一个线程执行直到执行完成后或异常，才会释放锁。所以可以保证synchronized代码块或方法只会有一个线程执行，保障了程序的有序性。

◆java中的各种锁机制(独立锁和共享锁、公平锁和非公平锁、可重入锁、轻量级锁和重量级锁等等)

参考：https://www.cnblogs.com/qifengshi/p/6831055.html

◆HashMap和ConcurrentHashMap的实现原理是什么，在JDK8以后实现上面有什么改进？

HashMap的底层实现原理都是基于数组加链表的方式实现的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的，如果定位到的数组位置不含链表（当前entry的next指向null）,那么对于查找，添加等操作很快，仅需一次寻址即可；如果定位到的数组包含链表，对于添加操作，其时间复杂度为O(n)，首先遍历链表，存在即覆盖，否则新增；对于查找操作来讲，仍需遍历链表，然后通过key对象的equals方法逐一比对查找。所以，性能考虑，HashMap中的链表出现越少，性能才会越好。

ConcurrentHashMap在HashMap的基础上，加入了Segment数组，通过分段锁实现线程安全性，参考：https://www.cnblogs.com/chengxiao/p/6842045.html

对于JDK8以后，链表的实现采用红黑树，提高链表查询的效率

java并发编程参考博文：https://www.cnblogs.com/chengxiao/category/921614.html

◆JDK8新增了哪些特性？

1、接口的默认方法：Java 8允许我们给接口添加一个非抽象的方法实现，只需要使用 default关键字即可，这个特征又叫做扩展方法
2、Lambda 表达式
3、函数式接口
4、方法与构造函数引用
5、集合操作的Stream 接口等等

参考：https://blog.csdn.net/haiyoung/article/details/52693212

◆MongDB(HBase)和关系型数据库有什么区别

MySQL：关系型数据库。在不同的引擎上有不同 的存储方式。查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。开源数据库的份额在不断增加，mysql的份额页在持续增长。缺点就是在海量数据处理的时候效率会显著变慢。

Mongodb：非关系型数据库(nosql ),属于文档型数据库。先解释一下文档的数据库，即可以存放xml、json、bson类型系那个的数据。这些数据具备自述性（self-describing），呈现分层的树状数据结构。数据结构由键值(key=>value)对组成。
存储方式：虚拟内存+持久化。
查询语句：是独特的Mongodb的查询方式。
适合场景：事件的记录，内容管理或者博客平台等等。
架构特点：可以通过副本集，以及分片来实现高可用。
数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。
成熟度与广泛度：新兴数据库，成熟度较低，Nosql数据库中最为接近关系型数据库，比较完善的DB之一，适用人群不断在增长。
优势：快速！在适量级的内存的Mongodb的性能是非常迅速的，它将热数据存储在物理内存中，使得热数据的读写变得十分快，
高扩展！自身的Failover机制！json的存储格式！

Hbase：是架构在hdfs上的列式存储，擅长rowkey的快速查询，但模糊匹配查询（其实是前模糊或全模糊）不擅长，但存储的量可以达到百亿甚至以上，比mongodb的存储量大多了。

◆垃圾回收机制的算法有哪些，有什么差异，虚拟机中常用的垃圾回收算法是什么，怎么判断一个对象是需要被垃圾回收器回收的？

垃圾回收机制算法：

1、标记-清除算法：主要有两个不足之处，一个是效率问题，标记和清除两个过程的效率都不高，另一个是空间问题，标记清除之后会产生大量的不连续的内存碎片，空间碎片太多可能会导致以后程序在运行过程中需要分配较大对象的时候，无法找到连续的内存而不得不提前触发另一次垃圾收集动作。

2、复制算法：将可用的内存按容量划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了，就将还存活着的对象复制到另一块上面去，然后把已经使用过的内存空间一次清理掉，效率比较高，代价是将内存缩小为原来的一半

3、标记-整理算法：过程和标记-清除算法一样，但是后续步骤不是直接对可回收的对象进行清理，而是让所有存活的对象向另一端移动，然后清理掉端边界以外的内存。

4、分代收集算法：虚拟机中比较通用的算法，它根据对象存活周期不同将内存划分为几块，一般将java堆分为新生代和老年代，在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，所以选择复制算法，老年代因为对象存活率比较高、没有额外空间对它进行分配担保，就是用标记清除或者标记整理算法。

判断对象是否需要被回收：

1、引用计数算法：给对象添加一个引用计数器，每当有一个地方引用它时，计数器的值就加1，当引用失效时，计数器的值就减1，任何时刻计数器为0的对象就是不可能再被使用的。

2、可达性分析算法：通过一系列的称为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连的时候，则证明此对象是不可用的。

需要被回收的对象也不是马上就要宣告死亡，而是暂时处于缓刑阶段，要真正宣告一个对象死亡，至少要经过两次标记过程：如果对象在进行任何可达性分析后发现没有与GC Roots相连接的引用链，那么它将会被第一次标记并进行一次筛选，筛选的条件是此对象是否有必要执行finalize方法，finalize方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次标记。

◆MySQL的数据存储引擎有哪些？

1、MyISAM存储引擎：不支持事务、也不支持外键，优势是访问速度快，对事务完整性没有 要求或者以select，insert为主的应用基本上可以用这个引擎来创建表支持3种不同的存储格式，分别是：静态表；动态表；压缩表
静态表：表中的字段都是非变长字段，这样每个记录都是固定长度的，优点存储非常迅速，容易缓存，出现故障容易恢复；缺点是占用的空间通常比动态表多（因为存储时会按照列的宽度定义补足空格）ps：在取数据的时候，默认会把字段后面的空格去掉，如果不注意会把数据本身带的空格也会忽略。
动态表：记录不是固定长度的，这样存储的优点是占用的空间相对较少；缺点：频繁的更新、删除数据容易产生碎片，需要定期执行OPTIMIZE TABLE或者myisamchk-r命令来改善性能
压缩表：因为每个记录是被单独压缩的，所以只有非常小的访问开支
2、InnoDB存储引擎：该存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比MyISAM引擎，写的处理效率会差一些，并且会占用更多的磁盘空间以保留数据和索引。 
InnoDB存储引擎的特点：支持自动增长列，支持外键约束
3、MEMORY存储引擎：Memory存储引擎使用存在于内存中的内容来创建表。每个memory表只实际对应一个磁盘文件，格式是.frm。memory类型的表访问非常的快，因为它的数据是放在内存中的，并且默认使用HASH索引，但是一旦服务关闭，表中的数据就会丢失掉。 
MEMORY存储引擎的表可以选择使用BTREE索引或者HASH索引，两种不同类型的索引有其不同的使用范围
Hash索引优点： 
Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。 
Hash索引缺点： 那么不精确查找呢，也很明显，因为hash算法是基于等值计算的，所以对于“like”等范围查找hash索引无效，不支持；
Memory类型的存储引擎主要用于哪些内容变化不频繁的代码表，或者作为统计操作的中间结果表，便于高效地对中间结果进行分析并得到最终的统计结果，。对存储引擎为memory的表进行更新操作要谨慎，因为数据并没有实际写入到磁盘中，所以一定要对下次重新启动服务后如何获得这些修改后的数据有所考虑。
4、MERGE存储引擎：Merge存储引擎是一组MyISAM表的组合，这些MyISAM表必须结构完全相同，merge表本身并没有数据，对merge类型的表可以进行查询，更新，删除操作，这些操作实际上是对内部的MyISAM表进行的。

◆Mysql执行计划需要看哪些参数以及代表什么含义？

1、id：在整个查询中SELECT的位置；

2、select_type：查询的类型，包括没有子查询的简单查询、UNION、子查询、外部查询、外部查询中的子查询或FROM语句中的子查询等，可选为SIMPLE、PRIMARY、UNION、DEPENDENT UNION、UNION RESULT、SUBQUERY、DEPENDENT SUBQUERY、DERIVED；

3、table：所查询的表名；

4、type：连接如何执行的情况。这里存在很多值，范围从const(最佳)到ALL(最差)，可选为system、const、eq_ref、ref、ref_or_null、index_merge、unique_subquery、index_subquery、range、index、ALL；

5、possible_keys：为了提高查询速度，在MySQL中可以使用的索引；

6、key：实际使用的索引；

7、key_len：索引的长度；

8、ref：使用哪一列或常数与key一起从表中选择行；

9、rows：MySQL需要在相应表中为了成功进行查询，进行检验的行的数量。为了得出总行数，MySQL必须扫描处理整个查询，再乘以每个表的行值；

10、Extra：其他信息，涉及MySQL如何处理查询，比如说，使用WHERE语句、使用一个索引、利用一个临时表等；

◆Redis持久化数据存储方式和优缺点？

RDB持久化可以在指定的时间间隔内生成数据集的时间点快照，快照形式是直接把内存中的数据保存到一个dump文件中，定时保存，保存策略

AOF持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集,AOF文件中全部以redis协议的格式来保存,新命令会被追加到文件的末尾,redis还可以在后台对AOF文件进行重写,文件的体积不会超出保存数据集状态所需要的实际大小,把所有的对redis的服务器进行修改的命令都存到一个文件里，命令的集合

redis还可以同时使用AOF持久化和RDB持久化,在这种情况下,当redis重启时,它会有限使用AOF文件来还原数据集,因为AOF文件保存的数据集通常比RDB文件所保存的数据集更加完

RDB 的优点

1、RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
2、RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。
3、RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
4、RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

RDB 的缺点
1、如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
2、每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF 的优点
1、使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
2、AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。
3、Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
4、AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 的缺点
1、对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
2、根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
3、AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的