## 前言嗨，大家好，好久不见。今天就总结下之前一个多月看到的一些面试题，难度不大，大佬可以直接路过，当然发发善心`点个赞`也是可以的❤️。进入正题，下面为`10月刊内容`，每三个问题为一个小节，也就是一个专题文章，我就不具体区分了，由于字数问题，也只节选了一些问题，大家见谅。另外答的不好的地方大家也可以留言`敲敲我`，感谢。要声明的是，大家不要背题哈，面试题只是为了帮助大家复习，扩展自己的知识面，取长补短，答案也是仅供参考。不懂的地方还是要自己好好看看相关知识点，只是看题也是没用的，最后希望大家都能找到满意的工作～ ## 10月刊内容 ### 网页中输入url，到渲染整个界面的整个过程，以及中间用了什么协议？ 1）过程分析：主要分为三步 * `DNS解析`。用户输入url后，需要通过DNS解析找到域名对应的ip地址，有了ip地址才能找到服务器端。首先会查找浏览器缓存，是否有对应的dns记录。再继续按照操作系统缓存—路由缓存—isp的dns服务器—根服务器的顺序进行DNS解析，直到找到对应的ip地址。 * `客户端（浏览器）和服务器交互`。浏览器根据解析到的ip地址和端口号发起HTTP请求，请求到达传输层，这里也就是TCP层，开始三次握手建立连接。服务器收到请求后，发送相应报文给客户端（浏览器），客户端收到相应报文并进行解析，得到html页面数据，包括html，js，css等。 * `客户端（浏览器）解析html数据`，构建DOM树，再构造呈现树（render树），最终绘制到浏览器页面上。 2）其中涉及到TCP/IP协议簇，包括DNS，TCP，IP，HTTP协议等等。 ### 具体介绍下TCP/IP TCP/IP一般指的是TCP/IP协议簇，主要包括了多个不同网络间实现信息传输涉及到的各种协议主要包括以下几层： * `应用层`：主要提供数据和服务。比如HTTP，FTP，DNS等 * `传输层`：负责数据的组装，分块。比如TCP，UDP等 * `网络层`：负责告诉通信的目的地，比如IP等 * `数据链路层`：负责连接网络的硬件部分，比如以太网，WIFI等 ### TCP的三次握手和四次挥手，为什么不是两次握手？为什么挥手多一次呢？客户端简称A，服务器端简称B 1）TCP建立连接需要三次握手 * A向B表示想跟B进行连接（A发送`syn`包，A进入`SYN_SENT`状态） * B收到消息，表示我也准备好和你连接了（B收到`syn`包，需要确认`syn`包，并且自己也发送一个`syn`包，即发送了`syn+ack`包，B进入`SYN_RECV`状态） * A收到消息，并告诉B表示我收到你也准备连接的信号了（A收到`syn+ack`包，向服务器发送确认包`ack`，AB进入`established`状态）开始连接。 2）TCP断开连接需要四次挥手 * A向B表示想跟B断开连接（A发送`fin`，进入`FIN_WAIT_1`状态） * B收到消息，但是B消息没发送完，只能告诉A我收到你的断开连接消息（B收到fin，发送ack，进入`CLOSE_WAIT`状态，A进入`FIN-WAIT-2`状态） * 过一会，B数据发送完毕，告诉A，我可以跟你断开了（B发送fin，进入`LAST_ACK`状态，A进入`TIME-WAIT`状态） * A收到消息，告诉B，可以他断开（A收到fin，发送ack，B进入`closed`状态） 3）为什么挥手多一次其实正常的断开和连接都是需要`四次`： * A发消息给B * B反馈给A表示正确收到消息 * B发送消息给A * A反馈给B表示正确收到消息。但是连接中，第二步和第三步是`可以合并`的，因为连接之前A和B是无联系的，所以没有其他情况需要处理。而断开的话，因为之前两端是正常连接状态，所以第二步的时候不能保证B之前的消息已经发送完毕，所以不能马上告诉A要断开的消息。这就是连接为什么可以少一步的原因。 4）为什么连接需要三次，而不是两次。正常来说，我给你发消息，你告诉我能收到，不就代表我们之前通信是正常的吗？ * 简单回答就是，`TCP是双向通信协议`，如果两次握手，不能保证B发给A的消息正确到达。 TCP 协议为了实现可靠传输，通信双方需要判断自己已经发送的数据包是否都被接收方收到，如果没收到，就需要重发。 TCP是怎么保证可靠传输的？ * `序列号和确认号`。比如连接的一方发送一段80byte数据，会带上一个序列号，比如101。接收方收到数据，回复确认号181（180+1），这样下一次发送消息就会从181开始发送了。所以握手过程中，比如A发送syn信号给B，初始序列号为120，那么B收到消息，回复`ack`消息，序列号为120+1。同时B发送`syn`信号给A，初始序列号为256，如果收不到A的回复消息，就会重发，否则丢失这个序列号，就无法正常完成后面的通信了。这就是三次握手的原因。 ### TCP和UDP的区别？ `TCP`提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接（三次握手），之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。 `UDP` 是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于`UDP`在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。所以总结下来就是： * TCP 是面向连接的，UDP 是面向无连接的 * TCP数据报头包括序列号，确认号，等等。相比之下UDP程序结构较简单。 * TCP 是面向字节流的，UDP 是基于数据报的 * TCP 保证数据正确性，UDP 可能丢包 * TCP 保证数据顺序，UDP 不保证可以看到`TCP`适用于稳定的应用场景，他会保证数据的正确性和顺序，所以一般的浏览网页，接口访问都使用的是`TCP`传输，所以才会有`三次握手`保证连接的稳定性。而UDP是一种结构简单的协议，不会考虑丢包啊，建立连接等。优点在于数据传输很快，所以适用于直播，游戏等场景。 ### HTTP的几种请求方法具体介绍常见的有四种： * `GET` 获取资源，没有body，幂等性 * `POST` 增加或者修改资源，有body * `PUT` 修改资源，有body，幂等性 * `DELETE` 删除资源，幂等性 ### HTTP请求和响应报文的格式，以及常用状态码 1）请求报文： ```kotlin //请求行（包括method、path、HTTP版本） GET /s HTTP/1.1 //Headers Host: www.baidu.com Content-Type: text/plain //Body 搜索**** ``` 2）响应报文 ```kotlin //状态行（包括HTTP版本、状态码，状态信息） HTTP/1.1 200 OK //Headers Content-Type: application/json; charset=utf-8 //Body [{"info":"xixi"}] ``` 3）常用状态码主要分为五种类型： * `1开头`，代表临时性消息，比如100（继续发送） * `2开头`，代表请求成功，比如200（OK） * `3开头`，代表重定向，比如304（内容无改变） * `4开头`，代表客户端的一些错误，比如403（禁止访问） * `5开头`，代表服务器的一些错误，比如500 ### 介绍对称加密和非对称加密 1）对称加密，即加密和解密算法不同，但是密钥相同。比如`DES，AES`算法。 ```kotlin 数据A --> 算法D（密钥S）--> 加密数据B 加密数据B --> 算法E（密钥S）--> 数据A ``` 优点：缺点：密钥有可能被破解，容易被伪造。传输过程中一旦密钥被其他人获知则可以进行数据解密。 2）非对称加密，即加密和解密算法相同，但是密钥不同。私钥自己保存，公钥提供给对方。比如`RSA，DSA`算法。 ```kotlin 数据A --> 算法D（公钥）--> 加密数据B 加密数据B --> 算法D（私钥）--> 数据A ``` 优点：安全，公钥即使被其他人获知，也无法解密数据。缺点：需要通信双方都有一套公钥和私钥 ### 数字签名的原理 1）首先，为什么需要数字签名？防止`被攻击，被伪造`。由于公钥是公开的，别人截获到公钥就能伪造数据进行传输，所以我们需要验证数据的来源。 2）怎么签名？由于公钥能解密私钥加密的数据，所以私钥也能解密公钥加密的数据。（上图非对称加密A和B代号互换即可）所以我们用公钥进行加密后，生成加密数据。再用私钥对数据的`摘要（hash值）`进行一次加密，那么私钥的这次加密就叫`签名`，也就是只有我自己可以进行加密的操作。所以传输数据流程就变成了`加密数据和签名数据`，如果解出来都是同样的数据及其摘要信息，那么则数据`安全可靠`。 ```kotlin 数据A --> 算法D（公钥）--> 加密数据B 数据A摘要--> 算法D（私钥）--> 签名数据C 加密数据B --> 算法D（私钥）--> 数据A -->数据A摘要签名数据C --> 算法D（公钥）--> 数据A摘要 ``` 这样加了签名数据，就能保证原数据也就是数据A确实是从正确的发送方发出的，且是没有被修改过的完整原数据。 ### Base64算法是什么，是加密算法吗？ * `Base64`是一种将二进制数据转换成64种字符组成的字符串的编码算法，主要用于非文本数据的传输，比如图片。可以将图片这种二进制数据转换成具体的字符串，进行保存和传输。 * 严格来说，不算。虽然它确实把一段二进制数据转换成另外一段数据，但是他的加密和解密是公开的，也就无秘密可言了。所以我更倾向于认为它是一种编码，每个人都可以用base64对二进制数据进行编码和解码。 * `面试加分项`：为了减少混淆，方便复制，减少数据长度，就衍生出一种base58编码。去掉了base64中一些容易混淆的数字和字母（数字0，字母O，字母I，数字1，符号+，符号/）大名鼎鼎的比特币就是用的改进后的base58编码，即`Base58Check`编码方式，有了校验机制，加入了hash值。 ### 为什么多线程同时访问（读写）同个变量，会有并发问题？ * Java 内存模型规定了所有的变量都存储在**主内存**中，每条线程有自己的工作内存。 * 线程的工作内存中保存了该线程中用到的变量的**主内存副本拷贝**，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。 * 线程访问一个变量，首先将变量从主内存拷贝到工作内存，对变量的写操作，**不会马上同步**到主内存。 * 不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行**数据同步**。 ### 说说原子性，可见性，有序性分别是什么意思？ * **原子性**：在一个操作中，CPU 不可以在中途暂停然后再调度，即不被中断操作，要么执行完成，要么就不执行。 * **可见性**：多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。 * **有序性**：程序执行的顺序按照代码的先后顺序执行。 ### 实际项目过程中，有用到多线程并发问题的例子吗？有，比如**单例模式**。由于单例模式的特殊性，可能被程序中不同地方多个线程**同时调用**，所以为了避免多线程并发问题，一般要采用`volatile+Synchronized`的方式进行变量，方法保护。 ```java private volatile static Singleton singleton; public static Singleton getSingleton4() { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null) { singleton = new Singleton(); } } } return singleton; } ``` ### 介绍几种启动模式。 * `standard`,默认模式，每次启动都会新建一个Activity实例，并进入当前任务栈 * `singleTop`，如果要启动的Activity在栈顶存在实例，则不会重新创建Activity，而是直接使用栈顶的Activity实例，并回调onNewIntent方法。 * `singleTask`，如果要启动的Activity在栈中存在实例，则不会重新创建Activity，而是直接使用栈里的Activity实例，并回调onNewIntent方法。并且会把这个实例放到栈顶，之前在这个Activity之上的都会被出栈销毁。 * `singleInstance`，有点单例的感觉，就是所启动的Activity会单独放在一个任务栈里，并且后续所有启动该Activity都会直接用这个实例，同样被重复调用的时候会调用并回调onNewIntent方法。 ### Activity依次A→B→C→B，其中B启动模式为singleTask，AC都为standard，生命周期分别怎么调用？如果B启动模式为singleInstance又会怎么调用？B启动模式为singleInstance不变，A→B→C的时候点击两次返回，生命周期如何调用。 1)A→B→C→B,B启动模式为`singleTask` * 启动A的过程，生命周期调用是 (A)onCreate→(A)onStart→(A)onResume * 再启动B的过程，生命周期调用是 (A)onPause→(B)onCreate→(B)onStart→(B)onResume→(A)onStop * B→C的过程同上 * C→B的过程，由于B启动模式为singleTask，所以B会调用onNewIntent，并且将B之上的实例移除，也就是C会被移出栈。所以生命周期调用是 (C)onPause→(B)onNewIntent→(B)onRestart→(B)onStart→(B)onResume→(C)onStop→(C)onDestory 2)A→B→C→B,B启动模式为`singleInstance` * 如果B为singleInstance，那么C→B的过程，C就不会被移除，因为B和C不在一个任务栈里面。所以生命周期调用是 (C)onPause→(B)onNewIntent→(B)onRestart→(B)onStart→(B)onResume→(C)onStop 3)A→B→C,B启动模式为`singleInstance`,点击两次返回键 * 如果B为singleInstance，A→B→C的过程，生命周期还是同前面一样正常调用。但是点击返回的时候，由于AC同任务栈，所以C点击返回，会回到A，再点击返回才回到B。所以生命周期是：(C)onPause→(A)onRestart→(A)onStart→(A)onResume→(C)onStop→(C)onDestory。 * 再次点击返回，就会回到B，所以生命周期是：**(A)onPause→(B)onRestart→(B)onStart→(B)onResume→(A)onStop→(A)onDestory**。 ### 屏幕旋转时Activity的生命周期，如何防止Activity重建。 * 切换屏幕的生命周期是：onConfigurationChanged->onPause->onSaveInstanceState->onStop->onDestroy->onCreate->onStart->onRestoreInstanceState->onResume * 如果需要防止旋转时候，`Activity`重新创建的话需要做如下配置：在`targetSdkVersion`的值小于或等于12时，配置 android:configChanges="orientation|keyboardHidden"，在`targetSdkVersion`的值大于12时，配置 android:configChanges="orientation|keyboardHidden|screenSize" ### 线程的三种启动实现写法 1）继承thread类 ```kotlin class MyThread :Thread(){ override fun run() { super.run() } } fun test(){ var t1=MyThread() t1.start() } ``` 2)实现runnable接口 ```kotlin class MyRunnable : Runnable { override fun run() { } } fun test() { var t1 = Thread(MyRunnable(),"test") t1.start() } ``` 3)实现 Callable 接口 ```kotlin class MyCallThread : Callable { override fun call(): String { return "i got it" } } fun test() { var task = FutureTask(MyCallThread()) var t1 = Thread(task, "test") t1.start() try { //获取结果 var result = task.get() } catch (e: Exception) { } } ``` 也有人表示其实是两个方法，因为第三个方法`FutureTask`也是实现了`Runnable`的方法，只不过表现方法不一样，然后带返回值。这个大家面试的时候可以都说上，然后说说自己的见解，毕竟要让面试官多多看到你的知识面。 ### 线程run和start的区别 * **start方法**,用start方法来启动线程，真正实现了多线程运行，这时无需等待run方法体中的代码执行完毕而直接继续执行后续的代码。通过调用Thread类的 start()方法来启动一个线程，这时此线程处于就绪（可运行）状态，并没有运行，一旦得到cpu时间片，就开始执行run()方法，这里的run()方法称为线程体，它包含了要执行的这个线程的内容，Run方法运行结束，此线程随即终止。 * **run方法**，run方法只是类的一个普通方法而已，如果直接调用Run方法，程序中依然只有主线程这一个线程，其程序执行路径还是只有一条，还是要顺序执行，还是要等待run方法体执行完毕后才可继续执行下面的代码，这样就没有达到写线程的目的。简单的说就是：调用start方法方可启动线程，而run方法只是thread类中的一个普通方法调用，不用启动新线程，还是在主线程里执行。 ### 线程的几种状态，相互之间是如何转化的 1） **初始状态（New）**。新创建了一个线程对象就进入了初始状态，也就是通过上述新建线程的几个方法就能进入该状态。 2） **可运行状态，就绪状态(RUNNABLE)**。线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取cpu 的使用权。以下几种方式会进入可运行状态： * 调用start方法。 * 拿到对象锁 * 调用yield方法 3）**运行状态(RUNNING)**。可运行状态(runnable)的线程获得了cpu 时间片，执行程序代码。线程调度程序从可运行池中选择一个线程作为当前线程，就会进入运行状态。 4）**阻塞状态(BLOCKED)**。线程正在运行的时候，被暂停，通常是为了等待某个时间的发生（比如说某项资源就绪）之后再继续运行。wait，sleep,suspend等方法都可以导致线程阻塞。 5）**死亡状态(DEAD)**。线程run()、main() 方法执行结束，或者因异常退出了run()方法，则该线程结束生命周期。死亡的线程不可再次复生。 ### String是java中的基本数据类型吗？是可变的吗？是线程安全的吗？ * `String`不是基本数据类型，java中把大数据类型是：`byte, short, int, long, char, float, double, boolean` * `String`是不可变的 * `String`是不可变类，一旦创建了String对象，我们就无法改变它的值。因此，它是**线程安全**的，可以安全地用于多线程环境中 ### 为什么要设计成不可变的呢？如果String是不可变的，那我们平时赋值是改的什么呢？ **1）为什么设计不可变** * `安全`。由于String广泛用于`java`类中的参数，所以安全是非常重要的考虑点。包括线程安全，打开文件，存储数据密码等等。 * String的不变性保证哈希码始终一，所以在用于HashMap等类的时候就不需要重新计算哈希码，`提高效率`。 * 因为java字符串是不可变的，可以在java运行时节省大量`java堆空间`。因为不同的字符串变量可以引用池中的相同的字符串。如果字符串是可变得话，任何一个变量的值改变，就会反射到其他变量，那`字符串池`也就没有任何意义了。 **2）平时使用双引号方式赋值的时候其实是返回的`字符串引用`,并不是改变了这个字符串对象** ### 浅谈一下String, StringBuffer，StringBuilder的区别？String的两种创建方式，在JVM的存储方式相同吗？ `String`是不可变类，每当我们对String进行操作的时候，总是会创建新的字符串。操作String很耗资源,所以Java提供了两个工具类来操作String - `StringBuffer和StringBuilder`。 **StringBuffer和StringBuilder**是可变类，`StringBuffer`是线程安全的，`StringBuilder`则不是线程安全的。所以在多线程对同一个字符串操作的时候，我们应该选择用StringBuffer。由于不需要处理多线程的情况，StringBuilder的效率比StringBuffer高。 **1） String常见的创建方式有两种** * String s1 = “Java” * String s2 = new String("Java") **2）存储方式不同** * 第一种，s1会先去字符串常量池中找字符串"Java”，如果有相同的字符则直接返回常量句柄，如果没有此字符串则会先在常量池中创建此字符串，然后再返回`常量句柄`，或者说字符串引用。 * 第二种，s2是直接在堆上创建一个变量对象，但不存储到字符串池，调用`intern`方法才会把此字符串保存到常量池中 ### 线程池是干嘛的，优点有哪些？线程池主要用作管理子线程，优点有： * 重用线程池中的线程，避免频繁创建和销毁线程所带来的`内存开销`。 * 有效控制线程的最大并发数，避免因线程之间抢占资源而导致的`阻塞现象`。 * 能够对线程进行简单的管理，提供`定时执行`以及指定`时间间隔循环执行`等功能。 ### 线程池的构造方法每个参数是什么意思，执行任务的流程 ```java public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler) {} ``` * `corePoolSize`：核心线程数。默认情况下线程池是空的，只是任务提交时才会创建线程。如果当前运行的线程数少于corePoolSize，则会创建新线程来处理任务；如果等于或者等于corePoolSize,则不再创建。如果调用线程池的prestartAllcoreThread方法，线程池会提前创建并启动所有的核心线程来等待任务。 * `maximumPoolSize`：线程池允许创建的最大线程数。如果任务队列满了并且线程数小于maximumPoolSize时，则线程池仍然会创建新的线程来处理任务。 * `keepAliveTime`：非核心线程闲置的超时事件。超过这个事件则回收。如果任务很多，并且每个任务的执行时间很短，则可以调大keepAliveTime来提高线程的利用率。另外，如果设置allowCoreThreadTimeOut属性来true时，keepAliveTime也会应用到核心线程上。 * `TimeUnit`：keepAliveTime参数的时间单位。可选的单位有天Days、小时HOURS、分钟MINUTES、秒SECONDS、毫秒MILLISECONDS等。 * `workQueue`：任务队列。如果当前线程数大于corePoolSzie，则将任务添加到此任务队列中。该任务队列是BlockingQueue类型的，即阻塞队列。 * `ThreadFactory`：线程工厂。可以使用线程工厂给每个创建出来的线程设置名字。一般情况下无须设置该参数。 * `RejectedExecutionHandler`：拒绝策略。这是当前任务队列和线程池都满了时所采取的应对策略，默认是AbordPolicy，表示无法处理新任务，并抛出RejectedExecutionException异常。其中，拒绝策略有四种： * `AbordPolicy`:无法处理新任务，并抛出RejectedExecutionException异常。 * `CallerRunsPolicy`:用调用者所在的线程来处理任务。此策略提供简单的反馈控制机制，能够减缓新任务的提交速度。 * `DiscardPolicy`：不能执行的任务，并将该任务删除。 * `DiscardOldestPolicy`:丢弃队列最近的任务，并执行当前的任务。执行任务流程： * 如果线程池中的线程数量未达到`核心线程的数量`，会直接启动一个核心线程来执行任务。 * 如果线程池中的线程数量已经达到或者超过核心线程的数量，那么任务会被插入到`任务队列`中排队等待执行。 * 如果任务队列无法插入新任务，说明任务队列已满，如果未达到规定的最大线程数量，则启动一个`非核心线程`来执行任务。 * 如果线程数量超过规定的最大值，则执行`拒绝策略`-RejectedExecutionHandler。 ### Android线程池主要分为哪几类，分别代表了什么？主要有四类：**FixedThreadPool、CachedThreadPool、SingleThreadExecutor、ScheduledTheadPool** 1） FixedThreadPool——可重用固定线程数的线程池 ```java public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue()); } ``` * 线程`数量固定`且都是核心线程：核心线程数量和最大线程数量都是nThreads； * 都是核心线程且不会被回收，快速相应外界请求； * 没有超时机制，任务队列也没有大小限制； * 新任务使用`核心线程`处理，如果没有空闲的核心线程，则排队等待执行。 2) CachedThreadPool——按需创建的线程池 ```java public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue()); } ``` * 线程数量不定，只有非核心线程，最大线程数`任意大`：传入核心线程数量的参数为0，最大线程数为Integer.MAX_VALUE； * 有新任务时使用`空闲线程`执行，没有空闲线程则创建新的线程来处理。 * 该线程池的每个空闲线程都有超时机制，时常为60s（参数：60L, TimeUnit.SECONDS），空闲超过60s则回收空闲线程。 * 适合执行大量的耗时较少的任务，当所有线程闲置`超过60s`都会被停止，所以这时几乎不占用系统资源。 3) SingleThreadExecutor——单线程的线程池 ```java public static ExecutorService newSingleThreadExecutor() { return new FinalizableDelegatedExecutorService (new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue())); } ``` * 只有`一个核心线程`，所有任务在同一个线程按顺序执行。 * 所有的外界任务统一到一个线程中，所以不需要处理线程同步的问题。 4) ScheduledThreadPool——定时和周期性的线程池 ```java private static final long DEFAULT_KEEPALIVE_MILLIS = 10L; public ScheduledThreadPoolExecutor(int corePoolSize) { super(corePoolSize, Integer.MAX_VALUE, DEFAULT_KEEPALIVE_MILLIS, MILLISECONDS, new DelayedWorkQueue()); } ``` * 核心线程`数量固定`，非核心线程数量`无限制`； * 非核心线程闲置超过10s会被回收； * 主要用于执行定时任务和具有固定周期的重复任务； ### 索引是什么，优缺点数据库索引,是数据库管理系统中一个排序的`数据结构`,以协助快速查询,更新数据库中表的数据.索引的实现通常使用`B树和变种的B+树`(mysql常用的索引就是B+树) 优点 * 通过创建索引,可以在查询的过程中,`提高系统的性能` * 通过创建唯一性索引,可以保证数据库表中每一行数据的`唯一性` * 在使用分组和排序子句进行数据检索时,可以减少查询中`分组和排序的时间` 缺点 * 创建索引和维护索引要`耗费时间`,而且时间随着数据量的增加而增大 * 索引需要占用物理空间,如果要建立聚簇索引,所需要的`空间会更大` * 在对表中的数据进行增加删除和修改时需要`耗费较多的时间`,因为索引也要动态地维护 ### 事务四大特性数据库事务必须具备`ACID`特性，ACID是**Atomic（原子性）、Consistency（一致性）、Isolation（隔离性）和Durability（持久性）**的英文缩写。 * 原子性一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被`回滚`到事务开始前的状态，就像这个事务从来没有执行过一样。 * 一致性事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于`一致性状态`。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。 * 隔离性指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的`完整数据空间`。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。 * 持久性指的是只要事务成功结束，它对数据库所做的更新就必须`永久保存下来`。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。 ### 讲讲几个范式范式的英文名称是`Normal Form`，它是英国人E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出`关系数据库模型`后总结出来的。范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。通常所用到的只是前三个范式，即：`第一范式（1NF），第二范式（2NF），第三范式（3NF）`。 * `第一范式`就是属性`不可分割`，每个字段都应该是不可再拆分的。比如一个字段是姓名（NAME），在国内的话通常理解都是姓名是一个不可再拆分的单位，这时候就符合第一范式；但是在国外的话还要分为FIRST NAME和LAST NAME，这时候姓名这个字段就是还可以拆分为更小的单位的字段，就不符合第一范式了。 * `第二范式`就是要求表中要有主键，表中其他其他字段都依赖于主键，因此第二范式只要记住`主键约束`就好了。比如说有一个表是学生表，学生表中有一个值唯一的字段学号，那么学生表中的其他所有字段都可以根据这个学号字段去获取，依赖主键的意思也就是相关的意思，因为学号的值是唯一的，因此就不会造成存储的信息对不上的问题，即学生001的姓名不会存到学生002那里去。 * `第三范式`就是要求表中不能有其他表中存在的、存储相同信息的字段，通常实现是在通过外键去建立关联，因此第三范式只要记住`外键约束`就好了。比如说有一个表是学生表，学生表中有学号，姓名等字段，那如果要把他的系编号，系主任，系主任也存到这个学生表中，那就会造成数据大量的冗余，一是这些信息在系信息表中已存在，二是系中有1000个学生的话这些信息就要存1000遍。因此第三范式的做法是在学生表中增加一个系编号的字段（外键），与系信息表做关联。 ### Recycleview和listview区别 * `Recycleview布局效果更多`，增加了纵向，表格，瀑布流等效果 * `Recycleview去掉了一些api`，比如setEmptyview，onItemClickListener等等，给到用户更多的自定义可能 * `Recycleview去掉了设置头部底部item的功能`，专向通过viewholder的不同type实现 * `Recycleview实现了一些局部刷新`，比如notifyitemchanged * `Recycleview自带了一些布局变化的动画效果`，也可以通过自定义ItemAnimator类实现自定义动画效果 * `Recycleview缓存机制更全面`，增加两级缓存，还支持自定义缓存逻辑 ### Recycleview有几级缓存，缓存过程？ Recycleview有四级缓存，分别是`mAttachedScrap(屏幕内)，mCacheViews(屏幕外)，mViewCacheExtension(自定义缓存)，mRecyclerPool(缓存池)` * `mAttachedScrap(屏幕内)`，用于屏幕内itemview快速重用，不需要重新createView和bindView * `mCacheViews(屏幕外)`，保存最近移出屏幕的ViewHolder，包含数据和position信息，复用时必须是相同位置的ViewHolder才能复用，应用场景在那些需要来回滑动的列表中，当往回滑动时，能直接复用ViewHolder数据，不需要重新bindView。 * `mViewCacheExtension(自定义缓存)`，不直接使用，需要用户自定义实现，默认不实现。 * `mRecyclerPool(缓存池)`，当cacheView满了后或者adapter被更换，将cacheView中移出的ViewHolder放到Pool中，放之前会把ViewHolder数据清除掉，所以复用时需要重新bindView。四级缓存按照顺序需要依次读取。所以**完整缓存流程**是： 1) 保存缓存流程： * 插入或是删除`itemView`时，先把屏幕内的ViewHolder保存至`AttachedScrap`中 * 滑动屏幕的时候，先消失的itemview会保存到`CacheView`，CacheView大小默认是2，超过数量的话按照先入先出原则，移出头部的itemview保存到`RecyclerPool缓存池`（如果有自定义缓存就会保存到自定义缓存里），RecyclerPool缓存池会按照itemview的`itemtype`进行保存，每个itemTyep缓存个数为5个，超过就会被回收。 2) 获取缓存流程： * AttachedScrap中获取，通过pos匹配holder——>获取失败，从`CacheView`中获取，也是通过pos获取holder缓存 ——>获取失败，从`自定义缓存`中获取缓存——>获取失败，从`mRecyclerPool`中获取 ——>获取失败，重新创建`viewholder`——createViewHolder并bindview。需要注意的是，如果从缓存池找到缓存，还需要重新bindview。 ### 说说RecyclerView性能优化。 * `bindViewHolder`方法是在UI线程进行的，此方法不能耗时操作，不然将会影响滑动流畅性。比如进行日期的格式化。 * 对于新增或删除的时候，可以使用`diffutil`进行局部刷新，少用全局刷新 * 对于`itemVIew`进行布局优化，比如少嵌套等。 * 25.1.0 (>=21)及以上使用` Prefetch` 功能，也就是预取功能，嵌套时且使用的是LinearLayoutManager，子RecyclerView可通过setInitialPrefatchItemCount设置预取个数 * 加大`RecyclerView缓存`，比如cacheview大小默认为2，可以设置大点，用空间来换取时间，提高流畅度 * 如果高度固定，可以设置`setHasFixedSize(true)`来避免requestLayout浪费资源，否则每次更新数据都会重新测量高度。 ```java void onItemsInsertedOrRemoved() { if (hasFixedSize) layoutChildren(); else requestLayout(); } ``` * 如果多个` RecycledView` 的 Adapter 是一样的，比如嵌套的 RecyclerView 中存在一样的 Adapter，可以通过设置 `RecyclerView.setRecycledViewPool(pool); `来共用一个 `RecycledViewPool`。这样就减少了创建VIewholder的开销。 * 在RecyclerView的元素比较高，一屏只能显示一个元素的时候，第一次滑动到第二个元素会卡顿。这种情况就可以通过设置额外的缓存空间，重写`getExtraLayoutSpace`方法即可。 ```java new LinearLayoutManager(this) { @Override protected int getExtraLayoutSpace(RecyclerView.State state) { return size; } }; ``` * 设置`RecyclerView.addOnScrollListener();`来在滑动过程中停止加载的操作。 * 减少对象的创建，比如设置监听事件，可以全局创建一个，所有view公用一个listener，并且放到`CreateView`里面去创建监听，因为CreateView调用要少于bindview。这样就减少了对象创建所造成的消耗 * 用`notifyDataSetChange`时，适配器不知道整个数据集中的那些内容以及存在，再重新匹配`ViewHolder`时会花生闪烁。设置adapter.setHasStableIds(true)，并重写`getItemId()`来给每个Item一个唯一的ID，也就是唯一标识，就使itemview的焦点固定，解决了闪烁问题。 ### 说说双重校验锁，以及volatile的作用先回顾下双重校验锁的原型，也就是单例模式的实现： ```java public class Singleton { private volatile static Singleton mSingleton; private Singleton() { } public Singleton getInstance() { if (null == mSingleton) { synchronized (Singleton.class) { if (null == mSingleton) { mSingleton = new Singleton(); } } } return mSingleton; } } ``` **有几个疑问需要解决：** * 为什么要加锁？ * 为什么不直接给getInstance方法加锁？ * 为什么需要双重判断是否为空？ * 为什么还要加volatile修饰变量？ **接下来一一解答：** * 如果不加锁的话，是`线程不安全`的，也就是有可能多个线程同时访问getInstance方法会得到两个实例化的对象。 * 如果给getInstance方法加锁，就每次访问mSingleton都需要加锁，增加了`性能开销` * 第一次判空是为了判断是否已经实例化，如果已经实例化就直接返回变量，不需要加锁了。第二次判空是因为走到加锁这一步，如果线程A已经实例化，等B获得锁，进入的时候其实对象已经实例化完成了，如果不二次判空就会`再次实例化`。 * 加volatile是为了`禁止指令重排`。指令重排指的是在程序运行过程中，并不是完全按照代码顺序执行的，会考虑到性能等原因，将不影响结果的指令顺序有可能进行调换。所以初始化的顺序本来是这三步： 1）分配内存空间 2）初始化对象 3）将对象指向分配的空间如果进行了指令重排，由于不影响结果，**所以2和3有可能被调换**。所以就变成了： 1）分配内存空间 2）将对象指向分配的空间 3）初始化对象就有可能会导致，假如线程A中已经进行到第二步，线程B进入第二次判空的时候，判断mSingleton不为空，就直接返回了，但是实际此时`mSingleton`还没有初始化。 ### synchronized和volatile的区别 * `volatile`本质是在告诉jvm当前变量在寄存器中的值是不确定的,需要从主存中读取,`synchronized`则是锁定当前变量,只有当前线程可以访问该变量,其他线程被阻塞住. * `volatile`仅能使用在变量级别,`synchronized`则可以使用在变量,方法. * `volatile`仅能实现变量的修改可见性,而`synchronized`则可以保证变量的修改可见性和原子性. * `volatile`不会造成线程的阻塞,而`synchronized`可能会造成线程的阻塞. * 当一个域的值依赖于它之前的值时，`volatile`就无法工作了，如n=n+1,n++等，也就是不保证原子性。 * 使用`volatile`而不是`synchronized`的唯一安全的情况是类中只有一个可变的域。 ### synchronized修饰static方法和修饰普通方法有什么区别 * `Synchronized修饰非静态方法`，实际上是对调用该方法的对象加锁，俗称“对象锁”。也就是锁住的是这个对象，即this。如果同一个对象在两个线程分别访问对象的两个同步方法，就会产生互斥，这就是对象锁，一个对象一次只能进入一个操作。 * `Synchronized修饰静态方法`，实际上是对该类对象加锁，俗称“类锁”。也就是锁住的是这个类，即xx.class。如果一个对象在两个线程中分别调用一个静态同步方法和一个非静态同步方法，由于静态方法会收到类锁限制，但是非静态方法会收到对象限制，所以两个方法并不是同一个对象锁，因此不会排斥。 ### 内存泄漏是什么，为什么会发生？ **内存泄漏（Memory Leak）**是指程序中己动态分配的堆内存由于某种原因程序`未释放或无法释放`，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。简单点说，手机给我们的应用提供了一定大小的`堆内存`，在不断创建对象的过程中，也在不断的`GC`(java的垃圾回收机制)，所以内存正常情况下会保持一个平稳的值。但是出现内存泄漏就会导致某个实例，比如Activity的实例，应用被某个地方引用到了，不能正常释放，从而导致内存`占用越来越大`，这就是**内存泄漏**。 ### 内存泄漏发生的情况有哪些？主要有`四类情况`： * 集合类泄漏 * 单例/静态变量造成的内存泄漏 * 匿名内部类/非静态内部类 * 资源未关闭造成的内存泄漏 1）集合类泄漏集合类添加元素后，仍引用着集合元素对象，导致该集合中的元素对象无法被回收，从而导致内存泄露。 ```java List