一. Spring
1、谈谈你对Spring的理解
关键点
- 企业框架，目前最流行，没有之一
- AOP、IOC、Spring MVC
2、Spring中用到了哪些设计模式
- 工厂模式，比如 BeanFactory
- 代理模式，在Aop实现中用到了JDK的动态代理
- 单例模式，Bean的创建默认就是单利的
3、IoC的启动过程
- Resource文件的定位，即找到bean的配置文件
- 通过特定的reader解析该bean配置文件，抽象成beanDefinition类
- 将beanDefinition向容器注册，写入到一个大的HashMap中
4、BeanFactory 和 ApplicationContext 区别
- 功能，BeanFactory负责读取bean配置，管理bean的加载，实例化，维护bean之间的依赖关系，负责bean的声明周期；ApplicationContext除了提供上述BeanFactory所能提供的功能之外，还提供了国际化支持、资源访问、事件传递、队Web的支持等功能
- BeanFactroy采用的是延迟加载形式来注入Bean的，即只有在使用到某个Bean时(调用getBean())，才对该Bean进行加载实例化；而ApplicationContext则相反，它是在容器启动时，一次性创建了所有的Bean。
- BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但两者之间的区别是：BeanFactory需要手动注册，而ApplicationContext则是自动注册
5、Bean 的生命周期
- 实例化一个Bean，也就是我们通常说的new
- 按照Spring上下文对实例化的Bean进行配置，也就是IOC注入
- 如果这个Bean实现了BeanNameAware接口，会调用它实现的setBeanName(String beanId)方法，此处传递的是Spring配置文件中Bean的ID
- 如果这个Bean实现了BeanFactoryAware接口，会调用它实现的setBeanFactory()，传递的是Spring工厂本身（可以用这个方法获取到其他Bean）
- 如果这个Bean实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文，该方式同样可以实现步骤4，但比4更好，以为ApplicationContext是BeanFactory的子接口，有更多的实现方法
- 如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor经常被用作是Bean内容的更改，并且由于这个是在Bean初始化结束时调用After方法，也可用于内存或缓存技术
- 如果这个Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法
- 如果这个Bean关联了BeanPostProcessor接口，将会调用postAfterInitialization(Object obj, String s)方法 注意：以上工作完成以后就可以用这个Bean了，那这个Bean是一个single的，所以一般情况下我们调用同一个ID的Bean会是在内容地址相同的实例
- 当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean接口，会调用其实现的destroy方法
- 最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法
6、Bean的作用域
- singleton(默认): 在Spring的IoC容器中只存在一个对象实例，所有该对象的引用都共享这个实例。Spring 容器只会创建该bean定义的唯一实例，这个实例会被保存到缓存中，并且对该bean的所有后续请求和引用都将返回该缓存中的对象实例，一般情况下，无状态的bean使用该scope。
- prototype:每次对该bean的请求都会创建一个新的实例，一般情况下，有状态的bean使用该scope。
- request：每次http请求将会有各自的bean实例，类似于prototype。
- session：在一个http session中，一个bean定义对应一个bean实例。
- global session：在一个全局的http session中，一个bean定义对应一个bean实例。典型情况下，仅在使用portlet context的时候有效。
7、AOP
实现原理：默认，接口基于JDK动态代理，类为cglib
注意事项
- 嵌套失效问题
- final类直接报错问题(动态代理的实现原理)
8、Spring MVC
请求过程
- 用户请求DispatchServlet
- DispatchServlet根据请求路径调用具体HandlerMapping返回一个HandlerExcutionChain
- DispatchServlet调用HandlerAdapter适配器
- HandlerAdapter调用具体的Handler处理业务
- Handler处理结束返回一个具体的ModelAndView给适配器
- 适配器将ModelAndView给DispatchServlet
- DispatchServlet把视图名称给ViewResolver视图解析器
- ViewResolver返回一个具体的视图给DispatchServlet
- 渲染视图，展示给用户
二. JVM
1、内存划分
JVM规范，将内存分为 程序计数器、Java栈，也叫虚拟机栈、本地方法栈、方法区、堆
- 程序计数器 程序指令保存，从当前指令到下一个指令，从程序计数器获取下一个指令的地址，直到执行所有的指令；线程私有
- Java栈(虚拟机栈) 保存方法栈帧，当调用一个方法，则新创建一个栈帧，当前的方法始终保持在栈帧的顶部；线程私有
- 本地方法栈 保存本地方法栈帧，当调用一个本地方法，则新创建一个栈帧，当前的方法始终保持在栈帧的顶部；线程私有
- 方法区 保存类信息、静态常量、常量；线程共享
- 堆 保存对象，最最主要的垃圾收集之处；线程共享
2、对象存活
- 引用计数算法：对对象引用进行计数，引用则计数器 +1，引用失效 -1；计数为 0 时候认为不在引用，可以进行回收；不能处理对象循环引用问题
- 可达性分析算法：主要采取此方式，采用虚拟机栈、类引用对象、常量对象、本地方法引用对象作为根，判断对象到根是否存在引用关系，不可达则认为不在引用，可以进行回收；
3、GC回收算法
- 标记-清除算法：对要回收的对象，先进行标志，后进行清除，你懂得；但是，久之，会存在内存不连续，比如，一次垃圾回收，回收了，(0,1)和(0,3)和(0,5)三个位置，但是没有回收(0，2)和(0，4)，那下次的内存，就无法使用(0，1)-(0，5)的连续空间；
- 复制算法：为改进上面的内存碎片问题而产生，对内存分为两部分，交替回收其中一部分，存活的对象复制到另一部分空间，你懂得；但是，有点浪费，比如，内存分为，(0,1)-(0,3)和(0,3)-(0,5)两个部分，某次回收(0,1)-(0,3)空间，将存活对象拷贝到(0,3)-(0,5)，而后在(0,1)-(0,3)分配对象；
- 标记-整理算法：为改进上面的内存浪费问题而产生，对要回收的对象，先进行标志，后进行清除，你懂得，然后，将存活的对象，进行整理，移动到边界位置，似的剩余空间连续；比如，一次垃圾回收，回收了，(0,1)和(0,3)和(0,5)三个位置，但是没有回收(0，2)和(0，4)，然后，将(0,2)和(0,4)移动到(0,1)和(0,2)，使得(0，3)-(0，5)的空间连续；
4、类加载过程
jvm中class类的加载过程，大致分为这几个步骤
- 加载（load）
- 根据全类名，加载类的二进制字节流
- 将字节流转存方法区
- 生成Class对象作为访问入口
- 验证（verify）
- class文件的格式验证，验证是否符合JVM规范
- class中的元数据验证，验证是否符合Java规范
- class的字节码验证，验证数据流控制流不会危害JVM环境
- 准备（prepare）
- 给变量分配内存
- 初始化零值（比如int默认为0，boolean默认为false）
- final变量直接赋值
- 解析
- 符号引用变为直接引用
- 类、字段、方法、接口方法解析
- 初始化
- 初始化变量
- 构造函数
- static块
5、双亲委派机制
Java中，大概有三种类型加载器，启动类加载器（Bootstrap）<- 标准扩展类加载器（Extension）<- 应用程序类加载器（Application ）<- 上下文类加载器(Custom)，从右到左，尽量父类进行加载，当父类无法进行加载时候，才会使用子类进行加载
- 意义
- 防止同一个JVM，内存中出现两份class二进制字节码
- 加载过程
- 从已加载的类查找是否已经存在，存在不需要再次加载
- 若不存在，则去parent中查找，存在不需要再次加载
- 若不存在，递归在parent中查找，直到找到为止
- 若找遍所有parent均不存在，且当前加载器已经没有parent加载器，则调用当前类加载器的findClass方法，如果能加载，结束
- 如果不能，则递归返回child类加载器，继续调用findClass方法，如果能加载，结束
- 如果找遍所有child的findClass方法，还是不能加载，则抛出异常
- 破坏双亲委派机制
- 将parent设为null
- 重写load(String,boolean)方法，改变类的查找机制。
三. 多线程
1、死锁的四个条件
- 互斥
- 请求与保持
- 不剥夺
- 循环等待
2、检查死锁
- Jconsole查看死锁
- Jstack查看死锁
3、volatile
- JMM
- 内存可见性
- 防止指令重排序
- 不能保证原子性
4、synchronized
作用
- 互斥访问
- 内存可见性
- 防止指令重排序
用法
- 修饰普通方法
- 修饰静态方法
- 修饰代码块
注意点
- 当一个线程在访问对象的 synchronized 方法，因为对象只有一把锁，其他线程无法获取该对象的锁，所以无法访问该对象的其他synchronized实例方法，但是其他线程还是可以访问该实例对象的其他非synchronized方法
- 实现原理为，对象监视器，Monitor
5、volatile vs synchronized vs lock
- 来源差异：volatile、synchronized为Java关键字； lock是Java类
- 代价开销：volatile不是锁，代价最小； lock是一般基于AQS，相对比synchronized代价小； synchronized代价最大
- 简单性：volatile、synchronized为Java关键字，JVM全权帮忙维护，只要我们能正确使用，不需要我们太多关心维护； lock是Java类，有很多方法可以调用，灵活性最好，但是需要自己控制锁的获取、释放
6、进程间通信
- 管道pipe
- 命名管道FIFO
- 消息队列MessageQueue
- 共享存储SharedMemory
- 信号量Semaphore
- 套接字Socket
- 信号 ( sinal )
7、原子操作类
-
CountDownLatch：
- 某线程需要等待多个线程执行完毕，再执行。
- 实现多个线程共同等待，同时开始执行任务，不可重用。(此类似于CyclicBarrier，可重用)
-
CyclicBarrier：
- CyclicBarrier允许一组线程互相等待，直到到达某个公共屏障点。
- 与CountDownLatch不同的是该barrier在释放等待线程后可以重用，所以称它为循环（Cyclic）的屏障
-
CountDownLatch、CyclicBarrier差别：
- CountDownLatch和CyclicBarrier都能够实现线程之间的等待，只不过它们侧重点不同： CountDownLatch一般用于某个线程A等待若干个其他线程执行完任务之后，它才执行； 而CyclicBarrier一般用于一组线程互相等待至某个状态，然后这一组线程再同时执行；
- CountDownLatch是不能够重用的，而CyclicBarrier是可以重用的。
-
Semaphore：
- Semaphore是一个计数信号量，它的本质是一个”共享锁”。
- 信号量维护了一个信号量许可集。线程可以通过调用acquire()来获取信号量的许可；当信号量中有可用的许可时，线程能获取该许可；否则线程必须等待，直到有可用的许可为止。 线程可以通过release()来释放它所持有的信号量许可。
- Semaphore其实和锁有点类似，它一般用于控制对某组资源的访问权限。
-
Exchanger：
- 用于进行线程间的数据交换。
- 两个线程通过exchange方法交换数据
- 该工具类的线程对象是成对的
-
ThreadLocal：
- 每个Thread 维护一个 ThreadLocalMap 映射表，这个映射表的 key 是 ThreadLocal实例本身，value 是真正需要存储的 Object。
- ThreadLocal 本身并不存储值，它只是作为一个 key 来让线程从 ThreadLocalMap 获取 value。值得注意的是图中的虚线，表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用作为 Key 的，弱引用的对象在 GC 时会被回收。
- ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用来引用它，那么系统 GC 的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏。
- ThreadLocal里面使用了一个存在弱引用的map, map的类型是ThreadLocal.ThreadLocalMap. Map中的key为一个threadlocal实例。这个Map的确使用了弱引用，不过弱引用只是针对key。每个key都弱引用指向threadlocal。 当把threadlocal实例置为null以后，没有任何强引用指向threadlocal实例，所以threadlocal将会被gc回收。 但是，我们的value却不能回收，而这块value永远不会被访问到了，所以存在着内存泄露。因为存在一条从current thread连接过来的强引用。只有当前thread结束以后，current thread就不会存在栈中，强引用断开，Current Thread、Map value将全部被GC回收。最好的做法是将调用threadlocal的remove方法，这也是等会后边要说的。
- 使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能导致内存泄漏。
- 分配使用了ThreadLocal又不再调用get(),set(),remove()方法，那么就会导致内存泄漏，因为这块内存一直存在。
写在最后
限于篇幅，本文只收录Spring、JVM、多线程的部分面试题；完整的面试题包含Kafka、Mysql、Tomcat、Docker、Spring、MyBatis、Nginx、Netty、Dubbo、Redis、Netty、Spring cloud、分布式、高并发、性能调优、微服务等架构技。笔者已经整理打包好了！
需要的朋友点击石墨文档， 即可免费领取面试资料和视频学习资料
以下是部分面试题截图
网友评论