字节跳动Java研发面试99题(含答案)：JVM+Spring+MySQL+线程池+锁 - 知乎

安宇雨 - 随手采集
2019-07-29 14:49:29
随手采集
0000-未整理-等待研究

JVM的内存结构

根据 JVM 规范，JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。

1. Java虚拟机栈：线程私有；每个方法在执行的时候会创建一个栈帧，存储了局部变量表，操作数栈，动态连接，方法返回地址等；每个方法从调用到执行完毕，对应一个栈帧在虚拟机栈中的入栈和出栈。

2. 堆：线程共享；被所有线程共享的一块内存区域，在虚拟机启动时创建，用于存放对象实例。

3. 方法区：线程共享；被所有线程共享的一块内存区域；用于存储已被虚拟机加载的类信息，常量，静态变量等。

4. 程序计数器：线程私有；是当前线程所执行的字节码的行号指示器，每条线程都要有一个独立的程序计数器，这类内存也称为“线程私有”的内存。

5. 本地方法栈：线程私有；主要为虚拟机使用到的Native方法服务。

为什么要用线程池

那先要明白什么是线程池

线程池是指在初始化一个多线程应用程序过程中创建一个线程集合，然后在需要执行新的任务时重用这些线程而不是新建一个线程。

使用线程池的好处

线程池改进了一个应用程序的响应时间。由于线程池中的线程已经准备好且等待被分配任务，应用程序可以直接拿来使用而不用新建一个线程。
线程池节省了CLR 为每个短生存周期任务创建一个完整的线程的开销并可以在任务完成后回收资源。
线程池根据当前在系统中运行的进程来优化线程时间片。
线程池允许我们开启多个任务而不用为每个线程设置属性。
线程池允许我们为正在执行的任务的程序参数传递一个包含状态信息的对象引用。
线程池可以用来解决处理一个特定请求最大线程数量限制问题。

msyql优化经验

1. 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

2. 应尽量避免在 where 子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。

3. 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

4. 任何地方都不要使用 select from t ，用具体的字段列表代替“”，不要返回用不到的任何字段。

5. 避免频繁创建和删除临时表，以减少系统表资源的消耗。诸如此类，等等等等......

什么是线程死锁？死锁如何产生？如何避免线程死锁？

死锁的介绍：

线程死锁是指由于两个或者多个线程互相持有对方所需要的资源，导致这些线程处于等待状态，无法前往执行。当线程进入对象的synchronized代码块时，便占有了资源，直到它退出该代码块或者调用wait方法，才释放资源，在此期间，其他线程将不能进入该代码块。当线程互相持有对方所需要的资源时，会互相等待对方释放资源，如果线程都不主动释放所占有的资源，将产生死锁。

死锁的产生的一些特定条件：

互斥条件：进程对于所分配到的资源具有排它性，即一个资源只能被一个进程占用，直到被该进程释放。
请求和保持条件：一个进程因请求被占用资源而发生阻塞时，对已获得的资源保持不放。
不剥夺条件：任何一个资源在没被该进程释放之前，任何其他进程都无法对他剥夺占用。
循环等待条件：当发生死锁时，所等待的进程必定会形成一个环路（类似于死循环），造成永久阻塞。

如何避免：

1. 加锁顺序：当多个线程需要相同的一些锁，但是按照不同的顺序加锁，死锁就很容易发生。如果能确保所有的线程都是按照相同的顺序获得锁，那么死锁就不会发生。当然这种方式需要你事先知道所有可能会用到的锁，然而总有些时候是无法预知的。

2. 加锁时限：加上一个超时时间，若一个线程没有在给定的时限内成功获得所有需要的锁，则会进行回退并释放所有已经获得的锁，然后等待一段随机的时间再重试。但是如果有非常多的线程同一时间去竞争同一批资源，就算有超时和回退机制，还是可能会导致这些线程重复地尝试但却始终得不到锁。

3. 死锁检测：死锁检测即每当一个线程获得了锁，会在线程和锁相关的数据结构中（map、graph等等）将其记下。除此之外，每当有线程请求锁，也需要记录在这个数据结构中。死锁检测是一个更好的死锁预防机制，它主要是针对那些不可能实现按序加锁并且锁超时也不可行的场景。

spring中Bean的作用域

1. singleton：Spring IoC容器中只会存在一个共享的Bean实例，无论有多少个Bean引用它，始终指向同一对象。Singleton作用域是Spring中的缺省作用域。

2. prototype：每次通过Spring容器获取prototype定义的bean时，容器都将创建一个新的Bean实例，每个Bean实例都有自己的属性和状态，而singleton全局只有一个对象。

3. request：在一次Http请求中，容器会返回该Bean的同一实例。而对不同的Http请求则会产生新的Bean，而且该bean仅在当前Http Request内有效。

4. session：在一次Http Session中，容器会返回该Bean的同一实例。而对不同的Session请求则会创建新的实例，该bean实例仅在当前Session内有效。

5. global Session：在一个全局的Http Session中，容器会返回该Bean的同一个实例，仅在使用portlet context时有效。

Spring框架中都用到了哪些设计模式？

1. 代理模式：在AOP和remoting中被用的比较多。

2. 单例模式：在spring配置文件中定义的bean默认为单例模式。

3. 模板方法模式：用来解决代码重复的问题。

4. 前端控制器模式：Spring提供了DispatcherServlet来对请求进行分发。

5. 依赖注入模式：贯穿于BeanFactory / ApplicationContext接口的核心理念。

6. 工厂模式：BeanFactory用来创建对象的实例。

springmvc的核心是什么，请求的流程是怎么处理的，控制反转怎么实现的

核心：控制反转和面向切面

请求处理流程：

首先用户发送请求到前端控制器，前端控制器根据请求信息（如URL）来决定选择哪一个页面控制器进行处理并把请求委托给它，即以前的控制器的控制逻辑部分；
页面控制器接收到请求后，进行功能处理，首先需要收集和绑定请求参数到一个对象，并进行验证，然后将命令对象委托给业务对象进行处理；处理完毕后返回一个ModelAndView（模型数据和逻辑视图名）；
前端控制器收回控制权，然后根据返回的逻辑视图名，选择相应的视图进行渲染，并把模型数据传入以便视图渲染；
前端控制器再次收回控制权，将响应返回给用户。

控制反转如何实现：