【BATJ面试必会】JAVA面试到底须要掌握什么？【上】

时间  2019-11-17
标签 BATJ面试必会 java 面试 到底 须要 掌握 什么 栏目 Java 繁體版
原文   原文链接

[参考地址：https://mp.weixin.qq.com/s/y-kBBLDSOVH0VnAQ2XcQlw]html

秋招几个月累积的知识点，东西太多，分两篇发，尽可能用(*)和加粗标注出高频知识点, 都是面试问过的或笔试考过的java

Java基础知识(*)node

  • https://blog.csdn.net/qq_16633405/article/details/79211002git

Spring Boot 启动 流程(*)github

  • https://juejin.im/post/5b679fbc5188251aad213110#heading-0面试

Spring 一些面试题(*)redis

  • https://www.ctolib.com/topics-35589.html算法

匿名内部类编译class(*)spring

  • https://blog.csdn.net/lazyer_dog/article/details/50669473sql

为何集合类没有实现Cloneable和Serializable接口？

  • https://www.nowcoder.com/questionTerminal/2a4902f67d5b49b6b4c05f9d7e422caf

自动装箱原理

  • https://www.jianshu.com/p/0ce2279c5691

final关键字

  • http://www.importnew.com/7553.html

基于Redis的分布式锁

  • https://segmentfault.com/a/1190000012919740

数据库分布式锁

  • http://www.hollischuang.com/archives/1716

防备DDOS攻击(*)

  • https://www.zhihu.com/question/19581905

何时Mysql调用行锁？(*)

  • https://blog.csdn.net/songwei128/article/details/43418343

CMS,G1(*)

  • https://crowhawk.github.io/2017/08/15/jvm_3/

内部类，外部类互访(*)

  • https://blog.csdn.net/jueblog/article/details/13434551

  • https://blog.csdn.net/Van_L_/article/details/54667365

设计模式(*)
熟背单例模式和工厂模式，会写适配器和建造者也行

  • https://www.jianshu.com/p/8a293e4a888e

  • https://segmentfault.com/a/1190000004255439

深拷贝，浅拷贝(*)

  • https://segmentfault.com/a/1190000010648514

泛型擦除

  • https://blog.csdn.net/briblue/article/details/76736356

Java 8 Stream, 函数编程

  • https://www.jianshu.com/p/0c07597d8311

  • https://www.jianshu.com/p/9bd647bcf1e3

中断线程

  • https://www.jianshu.com/p/264d4e1b76af

Lock，tryLock，lockInterruptibly区别

  • https://blog.csdn.net/u013851082/article/details/70140223

JUC

  • http://www.cnblogs.com/chenpi/p/5358579.html#_label2

  • http://www.cnblogs.com/chenpi/p/5614290.html

NIO

  • https://blog.csdn.net/u013063153/article/details/76473578

  • https://www.jianshu.com/p/052035037297

  • https://segmentfault.com/a/1190000006824196

Start和run区别(*)

  • https://blog.csdn.net/qq_36544760/article/details/79380963

jvm内存屏障

  • https://www.jianshu.com/p/2ab5e3d7e510

Java构造器能被重载，可是不能被重写(*)

  • https://blog.csdn.net/weixin_36513603/article/details/54968094

HttpSession

  • https://blog.csdn.net/zy2317878/article/details/80275463

Thread类的方法

  • https://blog.csdn.net/gxx_csdn/article/details/79210192

String是值类型，仍是引用类型(*)

  • https://blog.csdn.net/a220315410/article/details/27743607

Redis 实现消息队列

  • 消息/订阅+List

  • https://segmentfault.com/a/1190000012244418

minor gc full gc 区别(*)

  • https://blog.csdn.net/u010796790/article/details/52213708

Java如何查看死锁

  • https://blog.csdn.net/u014039577/article/details/52351626

  • https://juejin.im/post/5aaf6ee76fb9a028d3753534

c3p0，dbcp与druid

  • https://blog.csdn.net/qq_34359363/article/details/72763491

Spring Bean 生命周期(*)

  • https://www.jianshu.com/p/3944792a5fff

Spring的BeanFactory和ApplicationContext的区别?

  • ApplicationContext是实现类，继承ListableBeanFactory（继承BeanFactory），功能更多

  • ApplicationContext默认当即加载，BeanFactory懒加载

  • https://my.oschina.net/yao00jun/blog/215642

  • https://blog.csdn.net/qq_36748278/article/details/78264764

Java 如何有效地避免OOM：善于利用软引用和弱引用

  • https://www.cnblogs.com/dolphin0520/p/3784171.html

分布式数据库主键生成策略(*)

  • https://www.jianshu.com/p/a0a3aa888a49

  • https://tech.meituan.com/MT_Leaf.html

String底层(*)

  • https://blog.csdn.net/yadicoco49/article/details/77627302

count(1)、count(*)与count(列名)的执行区别

  • https://blog.csdn.net/iFuMI/article/details/77920767

主键，惟一索引区别

  • 1）主键必定会建立一个惟一索引，可是有惟一索引的列不必定是主键；

  • 2）主键不容许为空值，惟一索引列容许空值；

  • 3）一个表只能有一个主键，可是能够有多个惟一索引；

  • 4）主键能够被其余表引用为外键，惟一索引列不能够；

  • 5）主键是一种约束，而惟一索引是一种索引，是表的冗余数据结构，二者有本质的差异

死锁
产生死锁的四个必要条件：

  • 互斥条件：一个资源每次只能被一个进程使用。

  • 占有且等待：一个进程因请求资源而阻塞时，对已得到的资源保持不放。

  • 不可强行占有:进程已得到的资源，在末使用完以前，不能强行剥夺。

  • 循环等待条件:若干进程之间造成一种头尾相接的循环等待资源关系。

避免死锁：
https://segmentfault.com/a/1190000000378725

  • 确保全部的线程都是按照相同的顺序得到锁，那么死锁就不会发生.

  • 另一个能够避免死锁的方法是在尝试获取锁的时候加一个超时时间，这也就意味着在尝试获取锁的过程当中若超过了这个时限该线程则放弃对该锁请求。若一个线程没有在给定的时限内成功得到全部须要的锁，则会进行回退并释放全部已经得到的锁，而后等待一段随机的时间再重试。

  • 死锁检测是一个更好的死锁预防机制，它主要是针对那些不可能实现按序加锁而且锁超时也不可行的场景。

乐观锁，悲观锁(*)

  • https://blog.csdn.net/lovejj1994/article/details/79116272

公平锁、非公平锁

  • 公平锁（Fair）：加锁前检查是否有排队等待的线程，优先排队等待的线程，先来先得
    非公平锁（Nonfair）：加锁时不考虑排队等待问题，直接尝试获取锁，获取不到自动到队尾等待
    非公平锁性能比公平锁高5~10倍，由于公平锁须要在多核的状况下维护一个队列
    Java中的ReentrantLock 默认的lock()方法采用的是非公平锁。

OOM分析

  • https://blog.csdn.net/zheng12tian/article/details/40617369

JVM调优参数
知道-Xms，-Xmx，-XX:NewRatio=n，会算就行，笔试题考过

  • https://www.jianshu.com/p/a2a6a0995fee

堆设置

  • -Xms:初始堆大小
    -Xmx:最大堆大小
    -XX:NewSize=n:设置年轻代大小
    -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
    -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
    -XX:MaxPermSize=n:设置持久代大小

收集器设置

  • -XX:+UseSerialGC:设置串行收集器
    -XX:+UseParallelGC:设置并行收集器
    -XX:+UseParalledlOldGC:设置并行年老代收集器
    -XX:+UseConcMarkSweepGC:设置并发收集器

垃圾回收统计信息

  • -XX:+PrintGC
    -XX:+PrintGCDetails
    -XX:+PrintGCTimeStamps
    -Xloggc:filename

并行收集器设置

  • -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
    -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
    -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

并发收集器设置

  • -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU状况。
    -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

调优总结
年轻代大小选择

  • 响应时间优先的应用：尽量设大，直到接近系统的最低响应时间限制（根据实际状况选择）。在此种状况下，年轻代收集发生的频率也是最小的。同时，减小到达年老代的对象。
    吞吐量优先的应用：尽量的设置大，可能到达Gbit的程度。由于对响应时间没有要求，垃圾收集能够并行进行，通常适合8CPU以上的应用。

年老代大小选择

  • 响应时间优先的应用：年老代使用并发收集器，因此其大小须要当心设置，通常要考虑并发会话率和会话持续时间等一些参数。若是堆设置小了，能够会形成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；若是堆大了，则须要较长的收集时间。最优化的方案，通常须要参考如下数据得到：
    并发垃圾收集信息 持久代并发收集次数 传统GC信息 花在年轻代和年老代回收上的时间比例 减小年轻代和年老代花费的时间，通常会提升应用的效率
    吞吐量优先的应用：通常吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。缘由是，这样能够尽量回收掉大部分短时间对象，减小中期的对象，而年老代尽存放长期存活对象。

较小堆引发的碎片问题

  • 由于年老代的并发收集器使用标记、清除算法，因此不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样能够分配给较大的对象。可是，当堆空间较小时，运行一段时间之后，就会出现“碎片”，若是并发收集器找不到足够的空间，那么并发收集器将会中止，而后使用传统的标记、清除方式进行回收。若是出现“碎片”，可能须要进行以下配置：
    -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
    -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的状况下，这里设置多少次Full GC后，对年老代进行压缩

synchronized实现原理(*)

  • https://blog.csdn.net/javazejian/article/details/72828483

  • 内存对象头， Mark Word保存锁信息

  • JVM层：Monitor对象，字节码中的monitorenter 和 monitorexit 指令

  • 无锁，偏向锁，轻量级锁（自选），重量级锁

  • 可重入

  • notify/notifyAll和wait方法，在使用这3个方法时，必须处于synchronized代码块或者synchronized方法中，不然就会抛出IllegalMonitorStateException异常，这是由于调用这几个方法前必须拿到当前对象的监视器monitor对象，也就是说notify/notifyAll和wait方法依赖于monitor对象，在前面的分析中，咱们知道monitor 存在于对象头的Mark Word 中(存储monitor引用指针)，而synchronized关键字能够获取 monitor ，这也就是为何notify/notifyAll和wait方法必须在synchronized代码块或者synchronized方法调用的缘由.

synchronized, lock区别(*)

  • https://blog.csdn.net/u012403290/article/details/64910926

Spring容器中Bean的做用域(*)
当经过Spring容器建立一个Bean实例时，不只能够完成Bean实例的实例化，还能够为Bean指定特定的做用域。Spring支持以下5种做用域：

  • 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时，该做用域才有效

  • globalsession：每一个全局的HTTP
    Session，使用session定义的Bean都将产生一个新实例。典型状况下，仅在使用portlet
    context的时候有效。一样只有在Web应用中使用Spring时，该做用域才有效

    　　其中比较经常使用的是singleton和prototype两种做用域。对于singleton做用域的Bean，每次请求该Bean都将得到相同的实例。容器负责跟踪Bean实例的状态，负责维护Bean实例的生命周期行为；若是一个Bean被设置成prototype做用域，程序每次请求该id的Bean，Spring都会新建一个Bean实例，而后返回给程序。在这种状况下，Spring容器仅仅使用new 关键字建立Bean实例，一旦建立成功，容器不在跟踪实例，也不会维护Bean实例的状态。

    　　若是不指定Bean的做用域，Spring默认使用singleton做用域。Java在建立Java实例时，须要进行内存申请；销毁实例时，须要完成垃圾回收，这些工做都会致使系统开销的增长。所以，prototype做用域Bean的建立、销毁代价比较大。而singleton做用域的Bean实例一旦建立成功，能够重复使用。所以，除非必要，不然尽可能避免将Bean被设置成prototype做用域。

Spring IOC实现原理， 相关知识(*)

Spring 启动时读取应用程序提供的Bean配置信息，并在Spring容器中生成一份相应的Bean配置注册表，而后根据这张注册表实例化Bean，装配好Bean之间的依赖关系，为上层应用提供准备就绪的运行环境。



Bean缓存池：HashMap实现

Spring 经过一个配置文件描述 Bean 及 Bean 之间的依赖关系，利用 Java 语言的反射功能实例化 Bean 并创建 Bean 之间的依赖关系。 Spring 的 IoC 容器在完成这些底层工做的基础上，还提供了 Bean 实例缓存、生命周期管理、 Bean 实例代理、事件发布、资源装载等高级服务。

BeanFactory 是 Spring 框架的基础设施，面向 Spring 自己；

ApplicationContext 面向使用 Spring 框架的开发者，几乎全部的应用场合咱们都直接使用 ApplicationContext 而非底层的 BeanFactory。


enter image description here

BeanDefinitionRegistry： Spring 配置文件中每个节点元素在 Spring 容器里都经过一个 BeanDefinition 对象表示，它描述了 Bean 的配置信息。而 BeanDefinitionRegistry 接口提供了向容器手工注册 BeanDefinition 对象的方法。

BeanFactory 接口位于类结构树的顶端 ，它最主要的方法就是 getBean(String beanName)，该方法从容器中返回特定名称的 Bean，BeanFactory 的功能经过其余的接口获得不断扩展：

ListableBeanFactory：该接口定义了访问容器中 Bean 基本信息的若干方法，如查看Bean 的个数、获取某一类型 Bean 的配置名、查看容器中是否包括某一 Bean 等方法；

HierarchicalBeanFactory：父子级联 IoC 容器的接口，子容器能够经过接口方法访问父容器； 经过 HierarchicalBeanFactory 接口， Spring 的 IoC 容器能够创建父子层级关联的容器体系，子容器能够访问父容器中的 Bean，但父容器不能访问子容器的 Bean。Spring 使用父子容器实现了不少功能，好比在 Spring MVC 中，展示层 Bean 位于一个子容器中，而业务层和持久层的 Bean 位于父容器中。这样，展示层 Bean 就能够引用业务层和持久层的 Bean，而业务层和持久层的 Bean 则看不到展示层的 Bean。

ConfigurableBeanFactory：是一个重要的接口，加强了 IoC 容器的可定制性，它定义了设置类装载器、属性编辑器、容器初始化后置处理器等方法；

AutowireCapableBeanFactory：定义了将容器中的 Bean 按某种规则（如按名字匹配、按类型匹配等）进行自动装配的方法；

SingletonBeanRegistry：定义了容许在运行期间向容器注册单实例 Bean 的方法；

@Bean, @Component 区别

  • Componet 通常放在类上面，Bean放在方法上面，本身可控制是否生成bean.
    bean 通常会放在classpath scanning路径下面，会自动生成bean.
    有Componet /bean生成的bean都提供给autowire使用.

  • 在@Component中(@Component标注的类，包括@Service,@Repository, @Controller)使用@Bean注解和在@Configuration中使用是不一样的。在@Component类中使用方法或字段时不会使用CGLIB加强(及不使用代理类：调用任何方法，使用任何变量，拿到的是原始对象，后面会有例子解释)。而在@Configuration类中使用方法或字段时则使用CGLIB创造协做对象（及使用代理：拿到的是代理对象）;当调用@Bean注解的方法时它不是普通的Java语义，而是从容器中拿到的由Spring生命周期管理、被Spring代理甚至依赖于其余Bean的对象引用。在@Component中调用@Bean注解的方法和字段则是普通的Java语义，不通过CGLIB处理。

如何中止线程？

  • 主线程提供volatile boolean flag, 线程内while判断flag

  • 线程内while(!this.isInterrupted), 主线程里调用interrupt

  • if(this.isInterrupted) throw new InterruptedException() 或return，主线程里调用interrupt

  • 将一个线程设置为守护线程后，当进程中没有非守护线程后，守护线程自动结束

多线程实现方式？(*)

  • extends Thread

  • implements Runnable

  • implements Callable, 重写call, 返回future (主线程能够用线程池submit)

线程池(*)
线程池处理过程：

  • 若是当前运行的线程少于corePoolSize，则建立新线程来执行任务（注意，执行这一步骤须要获取全局锁）。

  • 若是运行的线程等于或多于corePoolSize，则将任务加入BlockingQueue。

  • 若是没法将任务加入BlockingQueue(队列已满)，则建立新的线程来处理任务(注意，执行这一步骤须要获取全局锁)。

  • 若是建立新线程将使当前运行的线程超出maximumPoolSize，任务将被拒绝，并调用RejectedExecutionHandler.rejectedExecution()方法。

四种线程池:

  • CachedThreadPool

  • FixedThreadPool

  • ScheduledThreadPool

  • SingleThreadExecutor

建立线程池的参数：

  • corePoolSize（线程池的基本大小）：当提交一个任务到线程池时，线程池会建立一个线程来执行任务，即便其余空闲的基本线程可以执行新任务也会建立线程，等到须要执行的任务数大于线程池基本大小时就再也不建立。若是调用了线程池的prestartAllCoreThreads()方法，线程池会提早建立并启动全部基本线程。

  • runnableTaskQueue（任务队列）：用于保存等待执行的任务的阻塞队列。能够选择如下几个阻塞队列。
    ArrayBlockingQueue：是一个基于数组结构的有界阻塞队列，此队列按FIFO（先进先出）原则对元素进行排序。
    LinkedBlockingQueue：一个基于链表结构的阻塞队列，此队列按FIFO排序元素，吞吐量一般要高于ArrayBlockingQueue。静态工厂方法Executors.newFixedThreadPool()使用了这个队列。
    SynchronousQueue：一个不存储元素的阻塞队列。每一个插入操做必须等到另外一个线程调用移除操做，不然插入操做一直处于阻塞状态，吞吐量一般要高于Linked-BlockingQueue，静态工厂方法Executors.newCachedThreadPool使用了这个队列。
    PriorityBlockingQueue：一个具备优先级的无限阻塞队列。

  • maximumPoolSize（线程池最大数量）：线程池容许建立的最大线程数。若是队列满了，而且已建立的线程数小于最大线程数，则线程池会再建立新的线程执行任务。值得注意的是，若是使用了无界的任务队列这个参数就没什么效果。

  • ThreadFactory：用于设置建立线程的工厂

  • RejectedExecutionHandler（饱和策略）：当队列和线程池都满了，说明线程池处于饱和状态，那么必须采起一种策略处理提交的新任务。这个策略默认状况下是AbortPolicy，表示没法处理新任务时抛出异常。在JDK
    1.5中Java线程池框架提供了如下4种策略。 AbortPolicy：直接抛出异常。 CallerRunsPolicy：只用调用者所在线程来运行任务。
    DiscardOldestPolicy：丢弃队列里最近的一个任务，并执行当前任务。 DiscardPolicy：不处理，丢弃掉。

**ArrayList,LinkedList **

  • ArrayList初始化能够指定大小，知道大小的建议指定
    arraylist添加元素的时候，须要判断存放元素的数组是否须要扩容（扩容大小是原来大小的1/2+1）

  • LinkedList添加、删除元素经过移动指针 LinkedList遍历比arraylist慢，建议用迭代器

  • ArrayList是实现了基于动态数组的数据结构，LinkedList基于链表的数据结构。
    对于随机访问get和set，ArrayList优于LinkedList，由于ArrayList能够随机定位，而LinkedList要移动指针一步一步的移动到节点处。（参考数组与链表来思考）

  • 对于新增和删除操做add和remove，LinedList比较占优点，只须要对指针进行修改便可，而ArrayList要移动数据来填补被删除的对象的空间。

HashMap原理(*)

  • HashMap最多只容许一条Entry的键为Null(多条会覆盖)，但容许多条Entry的值为Null

  • HashSet 自己就是在 HashMap 的基础上实现的.

  • 若负载因子越大，那么对空间的利用更充分，但查找效率的也就越低；若负载因子越小，那么哈希表的数据将越稀疏，对空间形成的浪费也就越严重。系统默认负载因子0.75

  • 调用put方法存值时，HashMap首先会调用Key的hashCode方法，而后基于此获取Key哈希码，经过哈希码快速找到某个桶，这个位置能够被称之为bucketIndex.若是两个对象的hashCode不一样，那么equals必定为false；不然，若是其hashCode相同，equals也不必定为 true。因此，理论上，hashCode可能存在碰撞的状况，当碰撞发生时，这时会取出bucketIndex桶内已存储的元素，并经过hashCode() 和 equals()来逐个比较以判断Key是否已存在。若是已存在，则使用新Value值替换旧Value值，并返回旧Value值；若是不存在，则存放新的键值对

    到桶中。所以，在 HashMap中，equals() 方法只有在哈希码碰撞时才会被用到。

  • 首先，判断key是否为null，若为null，则直接调用putForNullKey方法；若不为空，则先计算key的hash值，而后根据hash值搜索在table数组中的索引位置，若是table数组在该位置处有元素，则查找是否存在相同的key，若存在则覆盖原来key的value，不然将该元素保存在链头（最早保存的元素放在链尾）。此外，若table在该处没有元素，则直接保存。

  • HashMap 永远都是在链表的表头添加新元素。

hash()和indexFor()

static int hash(int h) {
    // This function ensures that hashCodes that differ only by
    // constant multiples at each bit position have a bounded
    // number of collisions (approximately 8 at default load factor).
    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}
static int indexFor(int h, int length) {
    return h & (length-1);  // 做用等价于取模运算，但这种方式效率更高
}
复制代码

  • hash() 方法用于对Key的hashCode进行从新计算，而 indexFor()方法用于生成这个Entry对象的插入位置。当计算出来的hash值与hashMap的(length-1)作了&运算后，会获得位于区间[0，length-1]的一个值。特别地，这个值分布的越均匀，HashMap 的空间利用率也就越高，存取效率也就越好，保证元素均匀分布到table的每一个桶中以便充分利用空间。

  • hash():使用hash()方法对一个对象的hashCode进行从新计算是为了防止质量低下的hashCode()函数实现。因为hashMap的支撑数组长度老是2 的幂次，经过右移可使低位的数据尽可能的不一样，从而使hash值的分布尽可能均匀。

  • indexFor():保证元素均匀分布到table的每一个桶中; 当length为2的n次方时，h&(length -1)就至关于对length取模，并且速度比直接取模要快得多，这是HashMap在速度上的一个优化.

扩容resize()和重哈希transfer()

void resize(int newCapacity) {
    Entry[] oldTable = table;
    int oldCapacity = oldTable.length;

    // 若 oldCapacity 已达到最大值，直接将 threshold 设为 Integer.MAX_VALUE
    if (oldCapacity == MAXIMUM_CAPACITY) {
        threshold = Integer.MAX_VALUE;
        return;             // 直接返回
    }

    // 不然，建立一个更大的数组
    Entry[] newTable = new Entry[newCapacity];

    //将每条Entry从新哈希到新的数组中
    transfer(newTable);

    table = newTable;
    threshold = (int) (newCapacity * loadFactor);  // 从新设定 threshold
}

void transfer(Entry[] newTable) {

    // 将原数组 table 赋给数组 src
    Entry[] src = table;
    int newCapacity = newTable.length;

    // 将数组 src 中的每条链从新添加到 newTable 中
    for (int j = 0; j < src.length; j++) {
        Entry<K,V> e = src[j];
        if (e != null) {
            src[j] = null;   // src 回收

            // 将每条链的每一个元素依次添加到 newTable 中相应的桶中
            do {
                Entry<K,V> next = e.next;

                // e.hash指的是 hash(key.hashCode())的返回值;
                // 计算在newTable中的位置，注意原来在同一条子链上的元素可能被分配到不一样的子链
                int i = indexFor(e.hash, newCapacity);   
                e.next = newTable[i];
                newTable[i] = e;
                e = next;
            } while (e != null);
        }
    }
}
复制代码

  • 为了保证HashMap的效率，系统必需要在某个临界点进行扩容处理，该临界点就是HashMap中元素的数量在数值上等于threshold（table数组长度*加载因子)

  • 重哈希的主要是一个从新计算原HashMap中的元素在新table数组中的位置并进行复制处理的过程

HashMap 的底层数组长度为什么老是2的n次方

  • 当底层数组的length为2的n次方时， h&(length - 1) 就至关于对length取模，并且速度比直接取模快得多，这是HashMap在速度上的一个优化

  • 不一样的hash值发生碰撞的几率比较小，这样就会使得数据在table数组中分布较均匀，空间利用率较高，查询速度也较快

ConcurrenytHashMap原理(*)


enter image description here

  • 经过锁分段技术保证并发环境下的写操做；
    经过 HashEntry的不变性、Volatile变量的内存可见性和加锁重读机制保证高效、安全的读操做；
    经过不加锁和加锁两种方案控制跨段操做的的安全性。

HashMap线程不安全

  • https://blog.csdn.net/justloveyou_/article/details/72783008

  • 在HashMap进行扩容重哈希时致使Entry链造成环。一旦Entry链中有环，势必会致使在同一个桶中进行插入、查询、删除等操做时陷入死循环。

Segment数组

static final class Segment<K,V> extends ReentrantLock 
implements Serializable {
    transient volatile int count;    // Segment中元素的数量，可见的
    transient int modCount;  //对count的大小形成影响的操做的次数（好比put或者remove操做）
    transient int threshold;      // 阈值，段中元素的数量超过这个值就会对Segment进行扩容
    transient volatile HashEntry<K,V>[] table;  // 链表数组
    final float loadFactor;  // 段的负载因子，其值等同于ConcurrentHashMap的负载因子
    ...
}
复制代码

  • Segment 类继承于 ReentrantLock 类，从而使得 Segment 对象能充当锁的角色

  • 在Segment类中，count 变量是一个计数器，它表示每一个 Segment 对象管理的 table 数组包含的 HashEntry 对象的个数，也就是 Segment 中包含的 HashEntry 对象的总数。特别须要注意的是，之因此在每一个 Segment 对象中包含一个计数器，而不是在 ConcurrentHashMap 中使用全局的计数器，是对 ConcurrentHashMap 并发性的考虑：由于这样当须要更新计数器时，不用锁定整个ConcurrentHashMap。事实上，每次对段进行结构上的改变，如在段中进行增长/删除节点(修改节点的值不算结构上的改变)，都要更新count的值，此外，在JDK的实现中每次读取操做开始都要先读取count的值。特别须要注意的是，count是volatile的，这使得对count的任何更新对其它线程都是当即可见的。modCount用于统计段结构改变的次数，主要是为了检测对多个段进行遍历过程当中某个段是否发生改变.table是一个典型的链表数组，并且也是volatile的，这使得对table的任何更新对其它线程也都是当即可见的。

HashEntry

static final class HashEntry<K,V> {
   final K key;                       // 声明 key 为 final 的
   final int hash;                   // 声明 hash 值为 final 的
   volatile V value;                // 声明 value 被volatile所修饰
   final HashEntry<K,V> next;      // 声明 next 为 final 的

    HashEntry(K key, int hash, HashEntry<K,V> next, V value) {
        this.key = key;
        this.hash = hash;
        this.next = next;
        this.value = value;
    }

    @SuppressWarnings("unchecked")
    static final <K,V> HashEntry<K,V>[] newArray(int i) {
    return new HashEntry[i];
    }
}
复制代码

  • 在HashEntry类中，key，hash和next域都被声明为final的，value域被volatile所修饰，所以HashEntry对象几乎是不可变的，这是ConcurrentHashmap读操做并不须要加锁的一个重要缘由

  • 因为value域被volatile修饰，因此其能够确保被读线程读到最新的值，这是ConcurrentHashmap读操做并不须要加锁的另外一个重要缘由

put(), get()

  • 不容许key值为null，也不容许value值为null

  • HashTable 和由同步包装器包装的HashMap每次只能有一个线程执行读或写操做，ConcurrentHashMap 在并发访问性能上有了质的提升。在理想状态下，ConcurrentHashMap 能够支持 16 个线程执行并发写操做（若是并发级别设置为 16），及任意数量线程的读操做。

    重哈希rehash()

  • ConcurrentHashMap的重哈希其实是对ConcurrentHashMap的某个段的重哈希，所以ConcurrentHashMap的每一个段所包含的桶位天然也就不尽相同

存在key-value为null的特殊状况

V get(Object key, int hash) {
        if (count != 0) {            // read-volatile，首先读 count 变量
            HashEntry<K,V> e = getFirst(hash);   // 获取桶中链表头结点
            while (e != null) {
                if (e.hash == hash && key.equals(e.key)) {    // 查找链中是否存在指定Key的键值对
                    V v = e.value;
                    if (v != null)  // 若是读到value域不为 null，直接返回
                        return v;   
                    // 若是读到value域为null，说明发生了重排序，加锁后从新读取
                    return readValueUnderLock(e); // recheck
                }
                e = e.next;
            }
        }
        return null;  // 若是不存在，直接返回null
    }
复制代码

  • 初始化HashEntry时发生的指令重排序致使的，也就是在HashEntry初始化完成以前便返回了它的引用

  • 加锁重读

读操做不须要加锁

  • 用HashEntery对象的不变性来下降读操做对加锁的需求；

  • 用Volatile变量协调读写线程间的内存可见性；

  • 若读时发生指令重排序现象，则加锁重读；

结构性操做的并发安全

remove(Object key, int hash, Object value) {
        lock();     // 加锁
        try {
            int c = count - 1;      
            HashEntry<K,V>[] tab = table;
            int index = hash & (tab.length - 1);        // 定位桶
            HashEntry<K,V> first = tab[index];
            HashEntry<K,V> e = first;
            while (e != null && (e.hash != hash || !key.equals(e.key)))  // 查找待删除的键值对
                e = e.next;

            V oldValue = null;
            if (e != null) {    // 找到
                V v = e.value;
                if (value == null || value.equals(v)) {
                    oldValue = v;
                    // All entries following removed node can stay
                    // in list, but all preceding ones need to be
                    // cloned.
                    ++modCount;
                    // 全部处于待删除节点以后的节点原样保留在链表中
                    HashEntry<K,V> newFirst = e.next;
                    // 全部处于待删除节点以前的节点被克隆到新链表中
                    for (HashEntry<K,V> p = first; p != e; p = p.next)
                        newFirst = new HashEntry<K,V>(p.key, p.hash,newFirst, p.value); 

                    tab[index] = newFirst;   // 将删除指定节点并重组后的链从新放到桶中
                    count = c;      // write-volatile，更新Volatile变量count
                }
            }
            return oldValue;
        } finally {
            unlock();          // finally子句解锁
        }
    }
复制代码

  • clear操做只是把ConcurrentHashMap中全部的桶置空，每一个桶以前引用的链表依然存在，只是桶再也不引用这些链表而已，而链表自己的结构并无发生任何修改。

  • put操做若是须要插入一个新节点到链表中时会在链表头部插入这个新节点，此时链表中的原有节点的连接并无被修改

  • 在执行remove操做时，原始链表并无被修改

  • 只要以前对链表作结构性修改操做的写线程M在退出写方法前写volatile变量count（segment中的，segment中元素的个数），读线程N就能读取到这个volatile变量count的最新值

跨segment操做

  • size(): JDK只须要在统计size先后比较modCount（Segment中的）是否发生变化就能够得知容器的大小是否发生变化

  • size方法主要思路是先在没有锁的状况下对全部段大小求和，这种求和策略最多执行RETRIES_BEFORE_LOCK次(默认是两次)：在没有达到RETRIES_BEFORE_LOCK以前，求和操做会不断尝试执行（这是由于遍历过程当中可能有其它线程正在对已经遍历过的段进行结构性更新）；在超过RETRIES_BEFORE_LOCK以后，若是还不成功就在持有全部段锁的状况下再对全部段大小求和。

JVM内存模型(*)
必考，熟背


enter image description here

  • 线程私有的数据区 包括 程序计数器、 虚拟机栈 和 本地方法栈

  • 线程共享的数据区 具体包括 Java堆 和 方法区

线程计数器

  • 在多线程状况下，当线程数超过CPU数量或CPU内核数量时，线程之间就要根据 时间片轮询抢夺CPU时间资源。也就是说，在任何一个肯定的时刻，一个处理器都只会执行一条线程中的指令。所以，为了线程切换后可以恢复到正确的执行位置，每条线程都须要一个独立的程序计数器去记录其正在执行的字节码指令地址。

虚拟机栈

  • 每一个方法从调用直至完成的过程，对应一个栈帧在虚拟机栈中入栈到出栈的过程

本地方法栈

  • 本地方法栈与Java虚拟机栈很是类似，也是线程私有的，区别是虚拟机栈为虚拟机执行 Java 方法服务，而本地方法栈为虚拟机执行 Native 方法服务。与虚拟机栈同样，本地方法栈区域也会抛出 StackOverflowError 和 OutOfMemoryError 异常

Java堆

  • Java 堆的惟一目的就是存放对象实例，几乎全部的对象实例（和数组）都在这里分配内存

  • Java堆能够处于物理上不连续的内存空间中，只要逻辑上是连续的便可。并且，Java堆在实现时，既能够是固定大小的，也能够是可拓展的，而且主流虚拟机都是按可扩展来实现的（经过-Xmx(最大堆容量) 和 -Xms(最小堆容量)控制）。若是在堆中没有内存完成实例分配，而且堆也没法再拓展时，将会抛出 OutOfMemoryError 异常。

  • TLAB (线程私有分配缓冲区) : 虚拟机为新生对象分配内存时，须要考虑修改指针 (该指针用于划份内存使用空间和空闲空间) 时的线程安全问题，由于存在可能出现正在给对象A分配内存，指针还未修改，对象B又同时使用原来的指针分配内存的状况。TLAB 的存在就是为了解决这个问题：每一个线程在Java堆中预先分配一小块内存 TLAB，哪一个线程须要分配内存就在本身的TLAB上进行分配，若TLAB用完并分配新的TLAB时，再加同步锁定，这样就大大提高了对象内存分配的效率。

方法区

  • 方法区与Java堆同样，也是线程共享的而且不须要连续的内存，其用于存储已被虚拟机加载的 类信息、常量、静态变量、即时编译器编译后的代码等数据

  • 运行时常量池：是方法区的一部分，用于存放编译期生成的各类 字面量 和 符号引用. 字面量比较接近Java语言层次的常量概念，如文本字符串、被声明为final的常量值. 符号引用:包括如下三类常量：类和接口的全限定名、字段的名称和描述符 和 方法的名称和描述符.

方法区的回收

  • 主要是针对 常量池的回收 （判断引用） 和 对类型的卸载

  • 回收类: 1) 该类全部的实例都已经被回收，也就是Java堆中不存在该类的任何实例加载 2) 该类的ClassLoader已经被回收 3) 该类对应的 java.lang.Class 对象没有在任何地方被引用，没法在任何地方经过反射访问该类的方法。

垃圾回收机制(*)
必考，熟背

引用计数法

  • 循环引用

可达性分析算法

  • 经过一系列的名为 “GC Roots” 的对象做为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）。当一个对象到 GC Roots 没有任何引用链相连（用图论的话来讲就是从 GC Roots 到这个对象不可达）时，则证实此对象是不可用的

  • 虚拟机栈(栈帧中的局部变量表)中引用的对象

  • 方法区中类静态属性引用的对象

  • 方法区中常量引用的对象

  • 本地方法栈中Native方法引用的对象

标记清除算法

  • 标记-清除算法分为标记和清除两个阶段。该算法首先从根集合进行扫描，对存活的对象对象标记，标记完毕后，再扫描整个空间中未被标记的对象并进行回收

  • 效率问题：标记和清除两个过程的效率都不高;

  • 空间问题：标记-清除算法不须要进行对象的移动，而且仅对不存活的对象进行处理，所以标记清除以后会产生大量不连续的内存碎片，空间碎片太多可能会致使之后在程序运行过程当中须要分配较大对象时，没法找到足够的连续内存而不得不提早触发另外一次垃圾收集动做

复制算法

  • 　复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，而后再把已使用过的内存空间一次清理掉。这种算法适用于对象存活率低的场景，好比新生代。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂状况，只要移动堆顶指针，按顺序分配内存便可，实现简单，运行高效。

  • 实践中会将新生代内存分为一块较大的Eden空间和两块较小的Survivor空间 (以下图所示)，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次地复制到另一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量的90% ( 80%+10% )，只有10% 的内存会被“浪费”。


  • 如今商用的虚拟机都采用这种算法来回收新生代

为何分代收集

  • 不一样的对象的生命周期(存活状况)是不同的，而不一样生命周期的对象位于堆中不一样的区域，所以对堆内存不一样区域采用不一样的策略进行回收能够提升 JVM 的执行效率.

新生代进入老生代的状况

  • 对象优先在Eden分配，当Eden区没有足够空间进行分配时，虚拟机将发起一次MinorGC。如今的商业虚拟机通常都采用复制算法来回收新生代，将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。 当进行垃圾回收时，将Eden和Survivor中还存活的对象一次性地复制到另一块Survivor空间上，最后处理掉Eden和刚才的Survivor空间。（HotSpot虚拟机默认Eden和Survivor的大小比例是8:1）当Survivor空间不够用时，须要依赖老年代进行分配担保。

  • 大对象直接进入老年代。所谓的大对象是指，须要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。

  • 长期存活的对象(-XX:MaxTenuringThreshold)将进入老年代。当对象在新生代中经历过必定次数（默认为15）的Minor GC后，就会被晋升到老年代中。

  • 动态对象年龄断定。为了更好地适应不一样程序的内存情况，虚拟机并非永远地要求对象年龄必须达到了MaxTenuringThreshold才能晋升老年代，若是在Survivor空间中相同年龄全部对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就能够直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

内存分配担保机制

  • 咱们知道若是对象在复制到Survivor区时若Survivor空间不足，则会出发担保机制，将对象转入老年代；但老年代的能力也不是无限的，所以须要在minor GC时作一个是否须要Major GC 的判断：

  • 若是老年代的剩余空间 < 以前转入老年代的对象的平均大小，则触发Major GC

  • 若是老年代的剩余空间 > 以前转入老年代的对象的平均大小，而且容许担保失败，则直接Minor GC，不须要作Full GC

  • 若是老年代的剩余空间 > 以前转入老年代的对象的平均大小，而且不容许担保失败，则触发Major GC

    出发点仍是尽可能为对象分配内存。可是通常会配置容许担保失败，避免频繁的去作Full GC。

标记整理算法

  • 标记整理算法的标记过程相似标记清除算法，但后续步骤不是直接对可回收对象进行清理，而是让全部存活的对象都向一端移动，而后直接清理掉端边界之外的内存，相似于磁盘整理的过程，该垃圾回收算法适用于对象存活率高的场景（老年代）

  • 无内存碎片

新生代、老年代、永久代

  • 新生代的目标就是尽量快速的收集掉那些生命周期短的对象，通常状况下，全部新生成的对象首先都是放在新生代的. 若是老年代也满了，就会触发一次FullGC，也就是新生代、老年代都进行回收。注意，新生代发生的GC也叫作MinorGC，MinorGC发生频率比较高，不必定等 Eden区满了才触发。

  • 老年代存放的都是一些生命周期较长的对象，就像上面所叙述的那样，在新生代中经历了N次垃圾回收后仍然存活的对象就会被放到老年代中

  • 永久代主要用于存放静态文件，如Java类、方法等

垃圾收集器


enter image description here

  • Serial收集器（复制算法): 新生代单线程收集器，标记和清理都是单线程，优势是简单高效；

  • Serial Old收集器 (标记-整理算法): 老年代单线程收集器，Serial收集器的老年代版本；

  • ParNew收集器 (复制算法):新生代收并行集器，其实是Serial收集器的多线程版本，在多核CPU环境下有着比Serial更好的表现；

  • Parallel Scavenge收集器 (复制算法): 新生代并行收集器，追求高吞吐量，高效利用 CPU。吞吐量 =用户线程时间/(用户线程时间+GC线程时间)，高吞吐量能够高效率的利用CPU时间，尽快完成程序的运算任务，适合后台应用等对交互相应要求不高的场景；

  • Parallel Old收集器 (标记-整理算法)： 老年代并行收集器，吞吐量优先，Parallel Scavenge收集器的老年代版本；

  • CMS(Concurrent Mark Sweep)收集器（标记-清除算法）：老年代并行收集器，以获取最短回收停顿时间为目标的收集器，具备高并发、低停顿的特色，追求最短GC回收停顿时间。

  • G1(Garbage First)收集器 (标记-整理算法)：Java堆并行收集器，G1收集器是JDK1.7提供的一个新收集器，G1收集器基于“标记-整理”算法实现，也就是说不会产生内存碎片。此外，G1收集器不一样于以前的收集器的一个重要特色是：G1回收的范围是整个Java堆(包括新生代，老年代)，而前六种收集器回收的范围仅限于新生代或老年代。

CMS,G1

  • https://blog.csdn.net/huanbia/article/details/75581423

内存泄露问题

  • 静态集合类: 如 HashMap、Vector 等集合类的静态使用最容易出现内存泄露，由于这些静态变量的生命周期和应用程序一致，全部的对象Object也不能被释放

  • 各类资源链接包括数据库链接、网络链接、IO链接等没有显式调用close关闭

  • 监听器的使用，在释放对象的同时没有相应删除监听器的时候也可能致使内存泄露。

MYSQL索引(*)

创建索引

  • 表的主键、外键必须有索引；

  • 数据量超过300的表应该有索引；

  • 常常与其余表进行链接的表，在链接字段上应该创建索引；

  • 常常出如今Where子句中的字段，特别是大表的字段，应该创建索引；

  • 索引应该建在选择性高的字段上；

  • 索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；

  • 频繁进行数据操做的表，不要创建太多的索引；

索引失效

  • 字符串不加单引号

  • 将要使用的索引列不是复合索引列表中的第一部分，则不会使用索引

  • 应尽可能避免在 where 子句中对字段进行 null 值判断，不然将致使引擎放弃使用索引而进行全表扫描，如：
    select id from t where num is null

  • 能够在num上设置默认值0，确保表中num列没有null值，而后这样查询：
    select id from t where num=0

  • 应尽可能避免在 where 子句中使用!=或<>操做符，不然将引擎放弃使用索引而进行全表扫描。优化器将没法经过索引来肯定将要命中的行数,所以须要搜索该表的全部行。

  • 应尽可能避免在 where 子句中使用 or 来链接条件 (用or分割开的条件，若是or前的条件中的列有索引，然后面的列中没有索引，那么涉及的索引都不会被用到)，不然将致使引擎放弃使用索引而进行全表扫描，如：
    select id from t where num=10 or num=20

  • 能够这样查询：
    select id from t where num=10
    union all
    select id from t where num=20

  • in 和 not in 也要慎用，由于IN会使系统没法使用索引,而只能直接搜索表中的数据。如：
    select id from t where num in(1,2,3)

  • 对于连续的数值，能用 between 就不要用 in 了：
    select id from t where num between 1 and 3

  • 尽可能避免在索引过的字符数据中，使用非打头字母%搜索。这也使得引擎没法利用索引。
    见以下例子：
    SELECT * FROM T1 WHERE NAME LIKE ‘%L%’
    SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’
    SELECT * FROM T1 WHERE NAME LIKE ‘L%’

  • 即便NAME字段建有索引，前两个查询依然没法利用索引完成加快操做，引擎不得不对全表全部数据逐条操做来完成任务。而第三个查询可以使用索引来加快操做

  • 应尽可能避免在 where 子句中对字段进行表达式操做，这将致使引擎放弃使用索引而进行全表扫描

  • 应尽可能避免在where子句中对字段进行函数操做，这将致使引擎放弃使用索引而进行全表扫描

  • 不要在 where 子句中的“=”左边进行函数、算术运算或其余表达式运算，不然系统将可能没法正确使用索引

共享锁，排他锁

  • InnoDB普通 select 语句默认不加锁(快照读，MYISAM会加锁)，而CUD操做默认加排他锁

  • MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是很是重要的，极大的增长了系统的并发性能，这也是为何现阶段，几乎全部的RDBMS，都支持了MVCC。

  • 多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增加的时间戳，为每一个修改保存一个版本，版本与事务时间戳关联，读操做只读该事务开始前的数据库的快照。 这样在读操做不用阻塞写操做，写操做不用阻塞读操做的同时，避免了脏读和不可重复读.MVCC 在语境中倾向于 “对多行数据打快照造平行宇宙”，然而 CAS 通常只是保护单行数据而已

  • 在MVCC并发控制中，读操做能够分红两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有多是历史版本)，不用加锁。当前读，读取的是记录的最新版本，而且，当前读返回的记录，都会加上锁，保证其余事务不会再并发修改这条记录。

  • SELECT … LOCK IN SHARE MODE ：共享锁(S锁, share locks)。其余事务能够读取数据，但不能对该数据进行修改，直到全部的共享锁被释放。

  • SELECT … FOR UPDATE：排他锁(X锁, exclusive locks)。若是事务对数据加上排他锁以后，则其余事务不能对该数据加任何的锁。获取排他锁的事务既能读取数据，也能修改数据。

  • InnoDB默认隔离级别 可重复读(Repeated Read)

  • 查询字段未加索引（主键索引、普通索引等）时，使用表锁

  • InnoDB行级锁基于索引实现

  • 索引数据重复率过高会致使全表扫描：当表中索引字段数据重复率过高，则MySQL可能会忽略索引，进行全表扫描，此时使用表锁。可以使用 force index 强制使用索引。

隔离级别

  • Read Uncommitted（读取未提交内容）: 在该隔离级别，全部事务均可以看到其余未提交事务的执行结果。本隔离级别不多用于实际应用，由于它的性能也不比其余级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

  • Read Committed（读取提交内容）: 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它知足了隔离的简单定义：一个事务只能看见已经提交事务所作的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），由于同一事务的其余实例在该实例处理其间可能会有新的commit，因此同一select可能返回不一样结果。

  • Repeatable Read（可重读）: 这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到一样的数据行。不过理论上，这会致使另外一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另外一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎经过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

  • Serializable（可串行化): 这是最高的隔离级别，它经过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每一个读的数据行上加上共享锁。在这个级别，可能致使大量的超时现象和锁竞争.

Spring IOC 怎么注入类，怎么实例化对象
实例化

  • Spring IoC容器则须要根据Bean定义里的配置元数据使用反射机制来建立Bean

  • 使用构造器实例化Bean 有参/无参;使用静态工厂实例化Bean;使用实例工厂实例化Bean.

  • 使用@Autowire注解注入的时机则是容器刚启动的时候就开始注入；注入以前要先初始化bean；ApplicationContext 的初始化和BeanFactory 有一个重大的区别：BeanFactory在初始化容器时，并未实例化Bean，直到第一次访问某个Bean 时才实例目标Bean；而ApplicationContext 则在初始化应用上下文时就实例化全部单实例的Bean。

注入

  • 接口、setter、构造器

AOP(*)
动态代理

@Aspect
public class Audience
{
    @Before("execution(** concert.Performance.perform(..))")        // 表演以前
    public void silenceCellPhones()
    {
        System.out.println("Silencing cell phones");
    }
    @Before("execution(** concert.Performance.perform(..))")        // 表演以前
    public void takeSeats()
    {
        System.out.println("Taking seats");
    }        
    @AfterReturning("execution(** concert.Performance.perform(..))")        // 表演以后
    public void applause()
    {
        System.out.println("CLAP CLAP CLAP!!!");
    }
    @AfterThrowing("execution(** concert.Performance.perform(..))")        // 表演失败以后
    public void demandRefound()
    {
        System.out.println("Demanding a refund");
    }
}   
复制代码

  • JDK动态代理，接口，用Proxy.newProxyInstance生成代理对象，InvocationHandler

  • CGLIB，类，用enhancer生成代理对象，MethodInteceptor

  • 若是目标对象实现了接口，默认状况下会采用JDK的动态代理实现AOP ; 若是目标对象实现了接口，能够强制使用CGLIB实现AOP ; 若是目标对象没有实现了接口，必须采用CGLIB库，spring会自动在JDK动态代理和CGLIB之间转换;

  • 切点+注解

  • AspectJ是一个比较牛逼的AOP框架，他能够对类的成员变量，方法进行拦截。因为 AspectJ 是 Java 语言语法和语义的扩展，因此它提供了本身的一套处理方面的关键字。除了包含字段和方法以外，AspectJ 的方面声明还包含切入点和通知成员。
    Spring AOP依赖的是 Spring 框架方便的、最小化的运行时配置，因此不须要独立的启动器。可是，使用这个技术，只能通知从 Spring 框架检索出的对象。Spring的AOP技术只能是对方法进行拦截。
    在spring AOP中咱们一样也可使用相似AspectJ的注解来实现AOP功能，可是这里要注意一下，使AspectJ的注解时，AOP的实现方式仍是Spring AOP。Spring缺省使用J2SE动态代理来做为AOP的代理，这样任何接口均可以被代理，Spring也可使用CGLIB代理，对于须要代理类而不是代理接口的时候CGLIB是颇有必要的。若是一个业务对象没有实现接口，默认就会使用CGLIB代理。
    Spring AOP和AscpectJ之间的关系：Spring使用了和aspectj同样的注解，并使用Aspectj来作切入点解析和匹配。可是spring AOP运行时仍旧是纯的spring AOP,并不依赖于Aspectj的编译器或者织入器

volatile和内存模型(*)

happens-before

  • 什么是happens-before
    令A和B表示两组操做，若是A happens-before B，那么由A操做引发的内存变化，在B开始执行以前，都应该是可见的。
    A happens-before B，不表明A在B以前执行.

  • 如何确保happen-before
    锁（互斥锁、读写锁等）、内存屏障

内存屏障

  • 内存屏障是一个指令，这个指令能够保证屏障先后的指令遵照必定的顺序，而且保证必定的可见性

  • 为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入

    内存屏障
    来禁止特定类型的处理器重排序。

Java内存模型

  • 屏蔽各个硬件平台和操做系统的内存访问差别，以实现让 Java 程序在各类平台下都能达到一致的内存访问效果

  • Java内存模型 规定全部的变量都是存在主存当中（相似于前面说的物理内存），每一个线程都有本身的工做内存（相似于前面的高速缓存）。线程对变量的全部操做都必须在工做内存中进行，而不能直接对主存进行操做，而且每一个线程不能访问其余线程的工做内存。

原子性

  • 只有简单的读取、赋值（并且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操做）才是原子操做

  • Java内存模型只保证了基本读取和赋值是原子性操做，若是要实现更大范围操做的原子性，能够经过 synchronized 和 Lock 来实现

可见性

  • 当一个共享变量被 volatile 修饰时，它会保证修改的值会当即被更新到主存，当有其余线程须要读取时，它会去内存中读取新值. 经过 synchronized 和 Lock 也可以保证可见性，synchronized 和 Lock 能保证同一时刻只有一个线程获取锁而后执行同步代码，而且 在释放锁以前会将对变量的修改刷新到主存当中，所以能够保证可见性

有序性

  • 指令重排序

  • 不能因为 synchronized 和 Lock 可让线程串行执行同步代码，就说它们能够保证指令不会发生重排序

volatile

  • 保证了不一样线程对共享变量进行操做时的可见性，即一个线程修改了某个变量的值，这个新值对其余线程来讲是 当即可见

  • 禁止进行指令重排序 (双重检查锁单例模式)

  • synchronized 也能够保证可见性，由于每次运行synchronized块 或者 synchronized方法都会致使线程工做内存与主存的同步，使得其余线程能够取得共享变量的最新值。也就是说，synchronized 语义范围不但包括 volatile 具备的可见性，也包括原子性，但不能禁止指令重排序，这是两者一个功能上的差别

i被volatile修饰，若是多线程来运行i++，那么是否能够达到理想的效果?

  • 不能，volatile不能保证操做的原子性

Sleep()和wait()的区别，使用wait()方法后，怎么唤醒线程(*)

笔试题常常考

  • sleep方法只让出了CPU，而并不会释放同步资源锁

  • wait()方法则是指当前线程让本身暂时退让出同步资源锁，以便其余正在等待该资源的线程获得该资源进而运行

  • sleep()方法能够在任何地方使用；wait()方法则只能在同步方法或同步块中使用

  • sleep()是线程线程类（Thread）的方法，调用会暂停此线程指定的时间，但监控依然保持，不会释放对象锁，到时间自动恢复；wait()是Object的方法，调用会放弃对象锁，进入等待队列，待调用notify()/notifyAll()唤醒指定的线程或者全部线程，才会进入锁池，再也不次得到对象锁才会进入运行状态

  • notify让以前调用wait的线程有权利从新参与线程的调度

Mybatis缓存(*)

  • 一级缓存的做用域是同一个SqlSession，在同一个sqlSession中两次执行相同的sql语句，第一次执行完毕会将数据库中查询的数据写到缓存（内存），第二次会从缓存中获取数据将再也不从数据库查询，从而提升查询效率。当一个sqlSession结束后该sqlSession中的一级缓存也就不存在了。Mybatis默认开启一级缓存。

  • 二级缓存是mapper级别的缓存，多个SqlSession去操做同一个Mapper的sql语句，多个SqlSession去操做数据库获得数据会存在二级缓存区域，多个SqlSession能够共用二级缓存，二级缓存是跨SqlSession的。不一样的sqlSession两次执行相同namespace下的sql语句且向sql中传递参数也相同即最终执行相同的sql语句，第一次执行完毕会将数据库中查询的数据写到缓存（内存），第二次会从缓存中获取数据将再也不从数据库查询，从而提升查询效率。Mybatis默认没有开启二级缓存须要在setting全局参数中配置开启二级缓存

  • https://segmentfault.com/a/1190000013678579

Redis的数据结构(*)

  • String, Hash, List, Set, ZSet

Hash底层结构

  • redis的哈希对象的底层存储可使用ziplist（压缩列表）和hashtable

Redis缓存怎么运行的？

  • 使用ANSI C编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库

  • 主从复制

  • 哨兵模式

持久化

  • 快照文件

  • AOF语句追加

过时策略

  • https://blog.csdn.net/xiangnan129/article/details/54928672

反向代理是什么？

  • 反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的链接请求，而后将请求转发给内部网络上的服务器，并将从服务器上获得的结果返回给internet上请求链接的客户端，此时代理服务器对外就表现为一个反向代理服务器。客户端只会得知反向代理的IP地址，而不知道在代理服务器后面的服务器簇的存在.

负载均衡是什么？

  • 负载平衡（Load balancing）是一种计算机技术，用来在多个计算机（计算机集群）、网络链接、CPU、磁盘驱动器或其余资源中分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。 使用带有负载平衡的多个服务器组件，取代单一的组件，能够经过冗余提升可靠性。负载平衡服务一般是由专用软件和硬件来完成。 主要做用是将大量做业合理地分摊到多个操做单元上进行执行,用于解决互联网架构中的高并发和高可用的问题。

单例模式(*)

必考，静态内部类，双重检查锁至少会写一个

  • 私有的构造方法；
    指向本身实例的私有静态引用；
    以本身实例为返回值的静态的公有方法。

双重检查锁

public class Singleton2 {

private volatile static Singleton2 singleton2;

private Singleton2() {
}

public static Singleton2 getSingleton2() {

    if (singleton2 == null) {
        synchronized (Singleton2.class) {
            if (singleton2 == null) {
                singleton2 = new Singleton2();
            }
        }
    }
    return singleton2;
}
}
复制代码

  • 第一个if (instance == null)，只有instance为null的时候，才进入synchronized.
    第二个if (instance == null)，是为了防止可能出现多个实例的状况。

  • volatile: 主要在于singleton = new Singleton()这句，这并不是是一个原子操做，事实上在 JVM 中这句话大概作了下面 3 件事情。
    　　1. 给 singleton 分配内存
    　　2. 调用 Singleton 的构造函数来初始化成员变量，造成实例
    　　3. 将singleton对象指向分配的内存空间（执行完这步 singleton才是非 null 了）可是在 JVM 的即时编译器中存在指令重排序的优化。
    　　也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序多是 1-2-3 也多是 1-3-2。若是是后者，则在 3 执行完毕、2 未执行以前，被线程二抢占了
    ，这时 instance 已是非 null 了（但却没有初始化），因此线程二会直接返回 instance，而后使用，而后瓜熟蒂落地报错。

静态内部类

public class Singleton1 {

private Singleton1() {
}

public static final Singleton1 getSingleton1() {
    return Singleton1Holder.singleton1;
}

private static class Singleton1Holder {
    private static final Singleton1 singleton1 = new Singleton1();
}
}
复制代码

ThreadLocal内存泄露？

static class ThreadLocalMap {
    /**
     * The entries in this hash map extend WeakReference, using
     * its main ref field as the key (which is always a
     * ThreadLocal object).  Note that null keys (i.e. entry.get()
     * == null) mean that the key is no longer referenced, so the
     * entry can be expunged from table.  Such entries are referred to
     * as "stale entries" in the code that follows.
     */
    static class Entry extends WeakReference<ThreadLocal> {
        /** The value associated with this ThreadLocal. */
        Object value;

        Entry(ThreadLocal k, Object v) {
            super(k);
            value = v;
        }
    }
    ...
}
复制代码

  • ThreadLocalMap里面对Key的引用是弱引用。那么，就存在这样的状况：当释放掉对threadlocal对象的强引用后，map里面的value没有被回收，但却永远不会被访问到了，所以ThreadLocal存在着内存泄露问题

  • Java为了最小化减小内存泄露的可能性和影响，在ThreadLocal进行get、set操做时会清除线程Map里全部key为null的value。因此最怕的状况就是，ThreadLocal对象设null了，开始发生“内存泄露”，而后使用线程池，线程结束后被放回线程池中而不销毁，那么若是这个线程一直不被使用或者分配使用了又再也不调用get/set方法，那么这个期间就会发生真正的内存泄露。所以，最好的作法是：在不使用该ThreadLocal对象时，及时调用该对象的remove方法去移除ThreadLocal.ThreadLocalMap中的对应Entry.

线程死锁检测工具？

  • Jconsole, Jstack, visualVM

线程池调优？

  • 设置最大线程数，防止线程资源耗尽；

  • 使用有界队列，从而增长系统的稳定性和预警能力(饱和策略)；

  • 根据任务的性质设置线程池大小：CPU密集型任务(CPU个数个线程)，IO密集型任务(CPU个数两倍的线程)，混合型任务(拆分)。

几种锁？

  • 无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争状况逐渐升级。锁能够升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提升得到锁和释放锁的效率

偏向锁

  • 偏向锁的目的是在某个线程得到锁以后，消除这个线程锁重入（CAS）的开销，看起来让这个线程获得了偏护

  • 偏向锁使用了一种等到竞争出现才释放锁的机制，因此当其余线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁

自旋锁

  • 线程的阻塞和唤醒须要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来讲是一件负担很重的工做. 所谓“自旋”，就是让线程去执行一个无心义的循环，循环结束后再去从新竞争锁，若是竞争不到继续循环，循环过程当中线程会一直处于running状态，可是基于JVM的线程调度，会出让时间片，因此其余线程依旧有申请锁和释放锁的机会。

  • 自旋锁省去了阻塞锁的时间空间（队列的维护等）开销，可是长时间自旋就变成了“忙式等待”，忙式等待显然还不如阻塞锁。因此自旋的次数通常控制在一个范围内，例如10,100等，在超出这个范围后，自旋锁会升级为阻塞锁。

轻量级锁

  • 线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。若是成功，当前线程得到锁，若是失败，则自旋获取锁，当自旋获取锁仍然失败时，表示存在其余线程竞争锁(两条或两条以上的线程竞争同一个锁)，则轻量级锁会膨胀成重量级锁。

重量级锁

  • 重量锁在JVM中又叫对象监视器（Monitor），它很像C中的Mutex，除了具有Mutex(0|1)互斥的功能，它还负责实现了Semaphore(信号量)的功能，也就是说它至少包含一个竞争锁的队列，和一个信号阻塞队列（wait队列），前者负责作互斥，后一个用于作线程同步。


enter image description here

innoDB和MyISAM的区别? (*)

  • https://www.jianshu.com/p/a957b18ba40d

  • InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，因此最好把多条SQL语言放在begin和commit之间，组成一个事务；

  • InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；

  • InnoDB是汇集索引，数据文件是和索引绑在一块儿的，必需要有主键，经过主键索引效率很高。可是辅助索引须要两次查询，先查询到主键，而后再经过主键查询到数据。所以，主键不该该过大，由于主键太大，其余索引也都会很大。而MyISAM是非汇集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。

  • InnoDB不保存表的具体行数，执行select count(*) from table时须要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只须要读出该变量便可，速度很快；

  • Innodb不支持全文索引，而MyISAM支持全文索引，查询效率上MyISAM要高；

索引失效 (*)

  • https://blog.csdn.net/qq_32331073/article/details/79041232

MySQL 索引实现原理+几种索引 (*)

普通索引

  • B+ree

  • MyISAM的B+Tree的叶子节点上的data，并非数据自己，而是数据存放的地址。主索引和辅助索引没啥区别，只是主索引中的key必定得是惟一的。这里的索引都是非聚簇索引.

InnoDB

  • InnoDB 的数据文件自己就是索引文件，B+Tree的叶子节点上的data就是数据自己，key为主键，这是聚簇索引。

  • 由于InnoDB的数据文件自己要按主键汇集，因此InnoDB要求表必须有主键（MyISAM能够没有），若是没有显式指定，则MySQL系统会自动选择一个能够 惟一 标识数据记录的列做为主键，若是不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段做为主键，这个字段长度为6个字节，类型为长整形。

  • 汇集索引这种实现方式使得按主键的搜索十分高效，可是辅助索引（普通索引）搜索须要 检索两遍索引：首先检索辅助索引得到主键，而后用主键到主索引中检索得到记录.

几种索引

  • 主键索引；

  • 惟一索引；

  • 普通索引；

  • 联合索引；

  • 全文索引。

辅助索引

  • https://www.cnblogs.com/xiangyangzhu/p/index.html

为何用B+树

  • https://blog.csdn.net/xlgen157387/article/details/79450295

  • 在MySQL中的数据通常是放在磁盘中的，读取数据的时候确定会有访问磁盘的操做，磁盘中有两个机械运动的部分，分别是盘片旋转和磁臂移动。盘片旋转就是咱们市面上所提到的多少转每分钟，而磁盘移动则是在盘片旋转到指定位置之后，移动磁臂后开始进行数据的读写。那么这就存在一个定位到磁盘中的块的过程，而定位是磁盘的存取中花费时间比较大的一块，毕竟机械运动花费的时候要远远大于电子运动的时间。当大规模数据存储到磁盘中的时候，显然定位是一个很是花费时间的过程，可是咱们能够经过B树进行优化，提升磁盘读取时定位的效率。

  • 为何B类树能够进行优化呢？咱们能够根据B类树的特色，构造一个多阶的B类树，而后在尽可能多的在结点上存储相关的信息，保证层数尽可能的少，以便后面咱们能够更快的找到信息，磁盘的I/O操做也少一些，并且B类树是平衡树，每一个结点到叶子结点的高度都是相同，这也保证了每一个查询是稳定的。

  • 总的来讲，B/B+树是为了磁盘或其它存储设备而设计的一种平衡多路查找树(相对于二叉，B树每一个内节点有多个分支)，与红黑树相比，在相同的的节点的状况下，一颗B/B+树的高度远远小于红黑树的高度(在下面B/B+树的性能分析中会提到)。B/B+树上操做的时间一般由存取磁盘的时间和CPU计算时间这两部分构成，而CPU的速度很是快，因此B树的操做效率取决于访问磁盘的次数，关键字总数相同的状况下B树的高度越小，磁盘I/O所花的时间越少。

B+树的插入删除

  • https://www.cnblogs.com/nullzx/p/8729425.html

为何说B+树比B树更适合数据库索引

  • B+树的磁盘读写代价更低：B+树的内部节点并无指向关键字具体信息的指针，所以其内部节点相对B树更小，若是把全部同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的须要查找的关键字也就越多，相对IO读写次数就下降了。

  • B+树的查询效率更加稳定：因为非终结点并非最终指向文件内容的结点，而只是叶子结点中关键字的索引。因此任何关键字的查找必须走一条从根结点到叶子结点的路。全部关键字查询的路径长度相同，致使每个数据的查询效率至关。

  • 因为B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只须要扫一遍叶子结点便可，可是B树由于其分支结点一样存储着数据，咱们要找到具体的数据，须要进行一次中序遍历按序来扫，因此B+树更加适合在区间查询的状况，因此一般B+树用于数据库索引。

JVM内存配置参数

  • -Xmx Java Heap最大值，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其余内存开销而定；

  • -Xms Java Heap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM能够保留默认值；

  • -Xmn Java Heap Young区大小，不熟悉最好保留默认值；

  • -Xss 每一个线程的Stack大小，不熟悉最好保留默认值；

extends 抽象类和 interface 区别 (*)

  • 接口（interface）能够说成是抽象类的一种特例，接口中的全部方法都必须是抽象的。

  • 接口中的方法定义默认为 public abstract 类型，接口中的成员变量类型默认为 public static final

  • 抽象类能够有构造方法，接口中不能有构造方法。

  • 抽象类中能够有普通成员变量，接口中没有普通成员变量。

  • 抽象类中能够包含非抽象的普通方法，接口中的全部方法必须都是抽象的，不能有非抽象的普通方法。

  • 抽象类中的抽象方法的访问类型能够是public，protected，但接口中的抽象方法只能是public类型的，而且默认即为public abstract类型。

  • 抽象类中能够包含静态(static)方法，接口中不能包含静态(static)方法。

  • 抽象类和接口中均可以包含静态成员变量(static)，抽象类中的静态成员变量的访问类型能够任意，但接口中定义的变量只能是public static final类型，而且默认即为public static final类型。

  • 一个类只能继承一个抽象类，可是能够实现多个接口。

  • 一个接口能够继承多个接口。

  • 抽象类所体现的是一种继承关系，要想使得继承关系合理，父类和派生类之间必须存在”is-a”关系关系，即父类和派生类在概念本质上应该是相同的。对于接口则否则，并不要求接口的实现者和接口定义在概念本质上是一致的，仅仅是实现了接口定义的契约而已，是”like-a”的关系。

Servlet生命周期

  • 调用 init() 方法初始化

  • 调用 service() 方法来处理客户端的请求

  • 调用 destroy() 方法释放资源，标记自身为可回收

  • 被垃圾回收器回收

Cookie, Session区别

  • cookie数据存放在客户的浏览器上，session数据放在服务器上

  • cookie不是很安全，别人能够分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session

  • session会在必定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用COOKIE

  • 单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程