mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-20 22:17:09 +08:00
Delete 美团-终结篇.md
This commit is contained in:
Snailclimb
parent
be1f00af73
commit
539028b289
353
面试必备/美团-终结篇.md
353
面试必备/美团-终结篇.md
@ -1,353 +0,0 @@
|
||||
|
||||
<!-- MarkdownTOC -->
|
||||
|
||||
- [一. Object类有哪些方法?](#一-object类有哪些方法)
|
||||
- [1.1 Object类的常见方法总结](#11-object类的常见方法总结)
|
||||
- [1.2 hashCode与equals](#12-hashcode与equals)
|
||||
- [1.2.1 hashCode（）介绍](#121-hashcode（）介绍)
|
||||
- [1.2.2 为什么要有hashCode](#122-为什么要有hashcode)
|
||||
- [1.2.3 hashCode（）与equals（）的相关规定](#123-hashcode（）与equals（）的相关规定)
|
||||
- [1.2.4 为什么两个对象有相同的hashcode值，它们也不一定是相等的？](#124-为什么两个对象有相同的hashcode值，它们也不一定是相等的？)
|
||||
- [1.3 ==与equals](#13-与equals)
|
||||
- [二 ConcurrentHashMap 相关问题](#二-concurrenthashmap-相关问题)
|
||||
- [2.1 ConcurrentHashMap 和 Hashtable 的区别](#21-concurrenthashmap-和-hashtable-的区别)
|
||||
- [2.2 ConcurrentHashMap线程安全的具体实现方式/底层具体实现](#22-concurrenthashmap线程安全的具体实现方式底层具体实现)
|
||||
- [JDK1.7（上面有示意图）](#jdk17（上面有示意图）)
|
||||
- [JDK1.8 （上面有示意图）](#jdk18-（上面有示意图）)
|
||||
- [三 谈谈 synchronized 和 ReenTrantLock 的区别](#三-谈谈-synchronized-和-reentrantlock-的区别)
|
||||
- [四 线程池了解吗？](#四-线程池了解吗？)
|
||||
- [4.1 为什么要用线程池？](#41-为什么要用线程池？)
|
||||
- [4.2 Java 提供了哪几种线程池？他们各自的使用场景是什么？](#42-java-提供了哪几种线程池？他们各自的使用场景是什么？)
|
||||
- [Java 主要提供了下面4种线程池](#java-主要提供了下面4种线程池)
|
||||
- [各种线程池的适用场景介绍](#各种线程池的适用场景介绍)
|
||||
- [4.3 创建的线程池的方式](#43-创建的线程池的方式)
|
||||
- [五 Nginx](#五-nginx)
|
||||
- [5.1 简单介绍一下Nginx](#51-简单介绍一下nginx)
|
||||
- [反向代理](#反向代理)
|
||||
- [负载均衡](#负载均衡)
|
||||
- [动静分离](#动静分离)
|
||||
- [5.2 为什么要用 Nginx ？](#52-为什么要用-nginx-？)
|
||||
- [5.3 Nginx 的四个主要组成部分了解吗？](#53-nginx-的四个主要组成部分了解吗？)
|
||||
|
||||
<!-- /MarkdownTOC -->
|
||||
|
||||
|
||||
> 下面这个问题，面试中经常出现。我觉得不论是出于应付面试还是说更好地掌握Java这门编程语言，大家都要掌握！
|
||||
|
||||
# 一. Object类有哪些方法?
|
||||
|
||||
### 1.1 Object类的常见方法总结
|
||||
|
||||
Object类是一个特殊的类，是所有类的父类。它主要提供了以下11个方法：
|
||||
|
||||
```java
|
||||
|
||||
public final native Class<?> getClass()//native方法，用于返回当前运行时对象的Class对象，使用了final关键字修饰，故不允许子类重写。
|
||||
|
||||
public native int hashCode() //native方法，用于返回对象的哈希码，主要使用在哈希表中，比如JDK中的HashMap。
|
||||
public boolean equals(Object obj)//用于比较2个对象的内存地址是否相等，String类对该方法进行了重写用户比较字符串的值是否相等。
|
||||
|
||||
protected native Object clone() throws CloneNotSupportedException//naitive方法，用于创建并返回当前对象的一份拷贝。一般情况下，对于任何对象 x，表达式 x.clone() != x 为true，x.clone().getClass() == x.getClass() 为true。Object本身没有实现Cloneable接口，所以不重写clone方法并且进行调用的话会发生CloneNotSupportedException异常。
|
||||
|
||||
public String toString()//返回类的名字@实例的哈希码的16进制的字符串。建议Object所有的子类都重写这个方法。
|
||||
|
||||
public final native void notify()//native方法，并且不能重写。唤醒一个在此对象监视器上等待的线程(监视器相当于就是锁的概念)。如果有多个线程在等待只会任意唤醒一个。
|
||||
|
||||
public final native void notifyAll()//native方法，并且不能重写。跟notify一样，唯一的区别就是会唤醒在此对象监视器上等待的所有线程，而不是一个线程。
|
||||
|
||||
public final native void wait(long timeout) throws InterruptedException//native方法，并且不能重写。暂停线程的执行。注意：sleep方法没有释放锁，而wait方法释放了锁 。timeout是等待时间。
|
||||
|
||||
public final void wait(long timeout, int nanos) throws InterruptedException//多了nanos参数，这个参数表示额外时间（以毫微秒为单位，范围是 0-999999）。 所以超时的时间还需要加上nanos毫秒。
|
||||
|
||||
public final void wait() throws InterruptedException//跟之前的2个wait方法一样，只不过该方法一直等待，没有超时时间这个概念
|
||||
|
||||
protected void finalize() throws Throwable { }//实例被垃圾回收器回收的时候触发的操作
|
||||
|
||||
```
|
||||
|
||||
> 问完上面这个问题之后，面试官很可能紧接着就会问你“hashCode与equals”相关的问题。
|
||||
|
||||
### 1.2 hashCode与equals
|
||||
|
||||
面试官可能会问你：“你重写过 hashcode 和 equals 么，为什么重写equals时必须重写hashCode方法？”
|
||||
|
||||
#### 1.2.1 hashCode（）介绍
|
||||
hashCode() 的作用是获取哈希码，也称为散列码；它实际上是返回一个int整数。这个哈希码的作用是确定该对象在哈希表中的索引位置。hashCode() 定义在JDK的Object.java中，这就意味着Java中的任何类都包含有hashCode() 函数。另外需要注意的是： Object 的 hashcode 方法是本地方法，也就是用 c 语言或 c++ 实现的，该方法通常用来将对象的 内存地址 转换为整数之后返回。
|
||||
|
||||
```java
|
||||
public native int hashCode();
|
||||
```
|
||||
|
||||
散列表存储的是键值对(key-value)，它的特点是：能根据“键”快速的检索出对应的“值”。这其中就利用到了散列码！（可以快速找到所需要的对象）
|
||||
|
||||
#### 1.2.2 为什么要有hashCode
|
||||
|
||||
|
||||
**我们以“HashSet如何检查重复”为例子来说明为什么要有hashCode：**
|
||||
|
||||
当你把对象加入HashSet时，HashSet会先计算对象的hashcode值来判断对象加入的位置，同时也会与其他已经加入的对象的hashcode值作比较，如果没有相符的hashcode，HashSet会假设对象没有重复出现。但是如果发现有相同hashcode值的对象，这时会调用equals（）方法来检查hashcode相等的对象是否真的相同。如果两者相同，HashSet就不会让其加入操作成功。如果不同的话，就会重新散列到其他位置。（摘自我的Java启蒙书《Head fist java》第二版）。这样我们就大大减少了equals的次数，相应就大大提高了执行速度。
|
||||
|
||||
|
||||
#### 1.2.3 hashCode（）与equals（）的相关规定
|
||||
|
||||
1. 如果两个对象相等，则hashcode一定也是相同的
|
||||
2. 两个对象相等,对两个对象分别调用equals方法都返回true
|
||||
3. 两个对象有相同的hashcode值，它们也不一定是相等的
|
||||
4. **因此，equals方法被覆盖过，则hashCode方法也必须被覆盖**
|
||||
5. hashCode()的默认行为是对堆上的对象产生独特值。如果没有重写hashCode()，则该class的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）
|
||||
|
||||
#### 1.2.4 为什么两个对象有相同的hashcode值，它们也不一定是相等的？
|
||||
|
||||
在这里解释一位小伙伴的问题。以下内容摘自《Head Fisrt Java》。
|
||||
|
||||
因为hashCode() 所使用的杂凑算法也许刚好会让多个对象传回相同的杂凑值。越糟糕的杂凑算法越容易碰撞，但这也与数据值域分布的特性有关（所谓碰撞也就是指的是不同的对象得到相同的 hashCode）。
|
||||
|
||||
我们刚刚也提到了 HashSet,如果 HashSet 在对比的时候，同样的 hashcode 有多个对象，它会使用 equals() 来判断是否真的相同。也就是说 hashcode 只是用来缩小查找成本。
|
||||
|
||||
> ==与equals 的对比也是比较常问的基础问题之一！
|
||||
|
||||
### 1.3 ==与equals
|
||||
|
||||
**==** : 它的作用是判断两个对象的地址是不是相等。即，判断两个对象是不是同一个对象。(基本数据类型==比较的是值，引用数据类型==比较的是内存地址)
|
||||
|
||||
**equals()** : 它的作用也是判断两个对象是否相等。但它一般有两种使用情况：
|
||||
|
||||
- 情况1：类没有覆盖equals()方法。则通过equals()比较该类的两个对象时，等价于通过“==”比较这两个对象。
|
||||
- 情况2：类覆盖了equals()方法。一般，我们都覆盖equals()方法来两个对象的内容相等；若它们的内容相等，则返回true(即，认为这两个对象相等)。
|
||||
|
||||
|
||||
**举个例子：**
|
||||
|
||||
```java
|
||||
public class test1 {
|
||||
public static void main(String[] args) {
|
||||
String a = new String("ab"); // a 为一个引用
|
||||
String b = new String("ab"); // b为另一个引用,对象的内容一样
|
||||
String aa = "ab"; // 放在常量池中
|
||||
String bb = "ab"; // 从常量池中查找
|
||||
if (aa == bb) // true
|
||||
System.out.println("aa==bb");
|
||||
if (a == b) // false，非同一对象
|
||||
System.out.println("a==b");
|
||||
if (a.equals(b)) // true
|
||||
System.out.println("aEQb");
|
||||
if (42 == 42.0) { // true
|
||||
System.out.println("true");
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**说明：**
|
||||
|
||||
- String中的equals方法是被重写过的，因为object的equals方法是比较的对象的内存地址，而String的equals方法比较的是对象的值。
|
||||
- 当创建String类型的对象时，虚拟机会在常量池中查找有没有已经存在的值和要创建的值相同的对象，如果有就把它赋给当前引用。如果没有就在常量池中重新创建一个String对象。
|
||||
|
||||
> 在[【备战春招/秋招系列5】美团面经总结进阶篇 （附详解答案）](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247484625&idx=1&sn=9c4fa1f7d4291a5fbd7daa44bac2b012&chksm=fd9852b0caefdba6edcf9a827aa4a17ddc97bf6ad2e5ee6f7e1aa1b443b54444d05d2b76732b&token=723699735&lang=zh_CN#rd) 这篇文章中，我们已经提到了一下关于 HashMap 在面试中常见的问题：HashMap 的底层实现、简单讲一下自己对于红黑树的理解、红黑树这么优秀，为何不直接使用红黑树得了、HashMap 和 Hashtable 的区别/HashSet 和 HashMap 区别。HashMap 和 ConcurrentHashMap 这俩兄弟在一般只要面试中问到集合相关的问题就一定会被问到，所以各位务必引起重视！
|
||||
|
||||
# 二 ConcurrentHashMap 相关问题
|
||||
|
||||
### 2.1 ConcurrentHashMap 和 Hashtable 的区别
|
||||
|
||||
ConcurrentHashMap 和 Hashtable 的区别主要体现在实现线程安全的方式上不同。
|
||||
|
||||
- **底层数据结构：** JDK1.7的 ConcurrentHashMap 底层采用 **分段的数组+链表** 实现，JDK1.8 采用的数据结构跟HashMap1.8的结构一样，数组+链表/红黑二叉树。Hashtable 和 JDK1.8 之前的 HashMap 的底层数据结构类似都是采用 **数组+链表** 的形式，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的；
|
||||
- **实现线程安全的方式（重要）：** ① **在JDK1.7的时候，ConcurrentHashMap（分段锁）** 对整个桶数组进行了分割分段(Segment)，每一把锁只锁容器其中一部分数据，多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。（默认分配16个Segment，比Hashtable效率提高16倍。） **到了 JDK1.8 的时候已经摒弃了Segment的概念，而是直接用 Node 数组+链表+红黑树的数据结构来实现，并发控制使用 synchronized 和 CAS 来操作。（JDK1.6以后 对 synchronized锁做了很多优化）** 整个看起来就像是优化过且线程安全的 HashMap，虽然在JDK1.8中还能看到 Segment 的数据结构，但是已经简化了属性，只是为了兼容旧版本；② **Hashtable(同一把锁)** :使用 synchronized 来保证线程安全，效率非常低下。当一个线程访问同步方法时，其他线程也访问同步方法，可能会进入阻塞或轮询状态，如使用 put 添加元素，另一个线程不能使用 put 添加元素，也不能使用 get，竞争会越来越激烈效率越低。
|
||||
|
||||
**两者的对比图：**
|
||||
|
||||
图片来源：http://www.cnblogs.com/chengxiao/p/6842045.html
|
||||
|
||||
HashTable:
|
||||
|
||||
|
||||
JDK1.7的ConcurrentHashMap：
|
||||
|
||||
JDK1.8的ConcurrentHashMap（TreeBin: 红黑二叉树节点
|
||||
Node: 链表节点）：
|
||||
|
||||
|
||||
### 2.2 ConcurrentHashMap线程安全的具体实现方式/底层具体实现
|
||||
|
||||
#### JDK1.7（上面有示意图）
|
||||
|
||||
首先将数据分为一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据时，其他段的数据也能被其他线程访问。
|
||||
|
||||
**ConcurrentHashMap 是由 Segment 数组结构和 HashEntry 数组结构组成**。
|
||||
|
||||
Segment 实现了 ReentrantLock,所以 Segment 是一种可重入锁，扮演锁的角色。HashEntry 用于存储键值对数据。
|
||||
|
||||
```java
|
||||
static class Segment<K,V> extends ReentrantLock implements Serializable {
|
||||
}
|
||||
```
|
||||
|
||||
一个 ConcurrentHashMap 里包含一个 Segment 数组。Segment 的结构和HashMap类似，是一种数组和链表结构，一个 Segment 包含一个 HashEntry 数组，每个 HashEntry 是一个链表结构的元素，每个 Segment 守护着一个HashEntry数组里的元素，当对 HashEntry 数组的数据进行修改时，必须首先获得对应的 Segment的锁。
|
||||
|
||||
#### JDK1.8 （上面有示意图）
|
||||
|
||||
ConcurrentHashMap取消了Segment分段锁，采用CAS和synchronized来保证并发安全。数据结构跟HashMap1.8的结构类似，数组+链表/红黑二叉树。
|
||||
|
||||
synchronized只锁定当前链表或红黑二叉树的首节点，这样只要hash不冲突，就不会产生并发，效率又提升N倍。
|
||||
|
||||
# 三 谈谈 synchronized 和 ReenTrantLock 的区别
|
||||
|
||||
**① 两者都是可重入锁**
|
||||
|
||||
两者都是可重入锁。“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。
|
||||
|
||||
**② synchronized 依赖于 JVM 而 ReenTrantLock 依赖于 API**
|
||||
|
||||
synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReenTrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。
|
||||
|
||||
**③ ReenTrantLock 比 synchronized 增加了一些高级功能**
|
||||
|
||||
相比synchronized，ReenTrantLock增加了一些高级功能。主要来说主要有三点：**①等待可中断；②可实现公平锁；③可实现选择性通知（锁可以绑定多个条件）**
|
||||
|
||||
- **ReenTrantLock提供了一种能够中断等待锁的线程的机制**，通过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
|
||||
- **ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。** ReenTrantLock默认情况是非公平的，可以通过 ReenTrantLock类的`ReentrantLock(boolean fair)`构造方法来制定是否是公平的。
|
||||
- synchronized关键字与wait()和notify/notifyAll()方法相结合可以实现等待/通知机制，ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition() 方法。Condition是JDK1.5之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个Lock对象中可以创建多个Condition实例（即对象监视器），**线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用notify/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例可以实现“选择性通知”** ，这个功能非常重要，而且是Condition接口默认提供的。而synchronized关键字就相当于整个Lock对象中只有一个Condition实例，所有的线程都注册在它一个身上。如果执行notifyAll()方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而Condition实例的signalAll()方法 只会唤醒注册在该Condition实例中的所有等待线程。
|
||||
|
||||
如果你想使用上述功能，那么选择ReenTrantLock是一个不错的选择。
|
||||
|
||||
**④ 两者的性能已经相差无几**
|
||||
|
||||
在JDK1.6之前，synchronized 的性能是比 ReenTrantLock 差很多。具体表示为：synchronized 关键字吞吐量岁线程数的增加，下降得非常严重。而ReenTrantLock 基本保持一个比较稳定的水平。我觉得这也侧面反映了， synchronized 关键字还有非常大的优化余地。后续的技术发展也证明了这一点，我们上面也讲了在 JDK1.6 之后 JVM 团队对 synchronized 关键字做了很多优化。JDK1.6 之后，synchronized 和 ReenTrantLock 的性能基本是持平了。所以网上那些说因为性能才选择 ReenTrantLock 的文章都是错的！JDK1.6之后，性能已经不是选择synchronized和ReenTrantLock的影响因素了！而且虚拟机在未来的性能改进中会更偏向于原生的synchronized，所以还是提倡在synchronized能满足你的需求的情况下，优先考虑使用synchronized关键字来进行同步！优化后的synchronized和ReenTrantLock一样，在很多地方都是用到了CAS操作。
|
||||
|
||||
|
||||
# 四 线程池了解吗？
|
||||
|
||||
|
||||
### 4.1 为什么要用线程池？
|
||||
|
||||
线程池提供了一种限制和管理资源（包括执行一个任务）。 每个线程池还维护一些基本统计信息，例如已完成任务的数量。
|
||||
|
||||
这里借用《Java并发编程的艺术》提到的来说一下使用线程池的好处：
|
||||
|
||||
- **降低资源消耗。** 通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
|
||||
- **提高响应速度。** 当任务到达时，任务可以不需要的等到线程创建就能立即执行。
|
||||
- **提高线程的可管理性。** 线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。
|
||||
|
||||
### 4.2 Java 提供了哪几种线程池？他们各自的使用场景是什么？
|
||||
|
||||
#### Java 主要提供了下面4种线程池
|
||||
|
||||
- **FixedThreadPool：** 该方法返回一个固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。
|
||||
- **SingleThreadExecutor：** 方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。
|
||||
- **CachedThreadPool：** 该方法返回一个可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。
|
||||
- **ScheduledThreadPoolExecutor：** 主要用来在给定的延迟后运行任务，或者定期执行任务。ScheduledThreadPoolExecutor又分为：ScheduledThreadPoolExecutor（包含多个线程）和SingleThreadScheduledExecutor （只包含一个线程）两种。
|
||||
|
||||
#### 各种线程池的适用场景介绍
|
||||
|
||||
- **FixedThreadPool：** 适用于为了满足资源管理需求，而需要限制当前线程数量的应用场景。它适用于负载比较重的服务器；
|
||||
- **SingleThreadExecutor：** 适用于需要保证顺序地执行各个任务并且在任意时间点，不会有多个线程是活动的应用场景。
|
||||
- **CachedThreadPool：** 适用于执行很多的短期异步任务的小程序，或者是负载较轻的服务器；
|
||||
- **ScheduledThreadPoolExecutor：** 适用于需要多个后台执行周期任务，同时为了满足资源管理需求而需要限制后台线程的数量的应用场景，
|
||||
- **SingleThreadScheduledExecutor：** 适用于需要单个后台线程执行周期任务，同时保证顺序地执行各个任务的应用场景。
|
||||
|
||||
### 4.3 创建的线程池的方式
|
||||
|
||||
**（1） 使用 Executors 创建**
|
||||
|
||||
我们上面刚刚提到了 Java 提供的几种线程池，通过 Executors 工具类我们可以很轻松的创建我们上面说的几种线程池。但是实际上我们一般都不是直接使用Java提供好的线程池，另外在《阿里巴巴Java开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 构造函数 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。
|
||||
|
||||
```java
|
||||
Executors 返回线程池对象的弊端如下：
|
||||
|
||||
FixedThreadPool 和 SingleThreadExecutor ： 允许请求的队列长度为 Integer.MAX_VALUE,可能堆积大量的请求，从而导致OOM。
|
||||
CachedThreadPool 和 ScheduledThreadPool ： 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致OOM。
|
||||
|
||||
```
|
||||
**（2） ThreadPoolExecutor的构造函数创建**
|
||||
|
||||
|
||||
我们可以自己直接调用 ThreadPoolExecutor 的构造函数来自己创建线程池。在创建的同时，给 BlockQueue 指定容量就可以了。示例如下：
|
||||
|
||||
```java
|
||||
private static ExecutorService executor = new ThreadPoolExecutor(13, 13,
|
||||
60L, TimeUnit.SECONDS,
|
||||
new ArrayBlockingQueue(13));
|
||||
```
|
||||
|
||||
这种情况下，一旦提交的线程数超过当前可用线程数时，就会抛出java.util.concurrent.RejectedExecutionException，这是因为当前线程池使用的队列是有边界队列，队列已经满了便无法继续处理新的请求。但是异常（Exception）总比发生错误（Error）要好。
|
||||
|
||||
**（3） 使用开源类库**
|
||||
|
||||
Hollis 大佬之前在他的文章中也提到了：“除了自己定义ThreadPoolExecutor外。还有其他方法。这个时候第一时间就应该想到开源类库，如apache和guava等。”他推荐使用guava提供的ThreadFactoryBuilder来创建线程池。下面是参考他的代码示例：
|
||||
|
||||
```java
|
||||
public class ExecutorsDemo {
|
||||
|
||||
private static ThreadFactory namedThreadFactory = new ThreadFactoryBuilder()
|
||||
.setNameFormat("demo-pool-%d").build();
|
||||
|
||||
private static ExecutorService pool = new ThreadPoolExecutor(5, 200,
|
||||
0L, TimeUnit.MILLISECONDS,
|
||||
new LinkedBlockingQueue<Runnable>(1024), namedThreadFactory, new ThreadPoolExecutor.AbortPolicy());
|
||||
|
||||
public static void main(String[] args) {
|
||||
|
||||
for (int i = 0; i < Integer.MAX_VALUE; i++) {
|
||||
pool.execute(new SubThread());
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
通过上述方式创建线程时，不仅可以避免OOM的问题，还可以自定义线程名称，更加方便的出错的时候溯源。
|
||||
|
||||
# 五 Nginx
|
||||
|
||||
### 5.1 简单介绍一下Nginx
|
||||
|
||||
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。 Nginx 主要提供反向代理、负载均衡、动静分离(静态资源服务)等服务。下面我简单地介绍一下这些名词。
|
||||
|
||||
#### 反向代理
|
||||
|
||||
谈到反向代理，就不得不提一下正向代理。无论是正向代理，还是反向代理，说到底，就是代理模式的衍生版本罢了
|
||||
|
||||
- **正向代理：**某些情况下，代理我们用户去访问服务器，需要用户手动的设置代理服务器的ip和端口号。正向代理比较常见的一个例子就是 VPN了。
|
||||
- **反向代理：** 是用来代理服务器的，代理我们要访问的目标服务器。代理服务器接受请求，然后将请求转发给内部网络的服务器，并将从服务器上得到的结果返回给客户端，此时代理服务器对外就表现为一个服务器。
|
||||
|
||||
通过下面两幅图，大家应该更好理解（图源：http://blog.720ui.com/2016/nginx_action_05_proxy/）：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
所以，简单的理解，就是正向代理是为客户端做代理，代替客户端去访问服务器，而反向代理是为服务器做代理，代替服务器接受客户端请求。
|
||||
|
||||
#### 负载均衡
|
||||
|
||||
在高并发情况下需要使用，其原理就是将并发请求分摊到多个服务器执行，减轻每台服务器的压力，多台服务器(集群)共同完成工作任务，从而提高了数据的吞吐量。
|
||||
|
||||
Nginx支持的weight轮询（默认）、ip_hash、fair、url_hash这四种负载均衡调度算法，感兴趣的可以自行查阅。
|
||||
|
||||
负载均衡相比于反向代理更侧重的时将请求分担到多台服务器上去，所以谈论负载均衡只有在提供某服务的服务器大于两台时才有意义。
|
||||
|
||||
#### 动静分离
|
||||
|
||||
动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路。
|
||||
|
||||
### 5.2 为什么要用 Nginx ？
|
||||
|
||||
> 这部分内容参考极客时间—[Nginx核心知识100讲的内容](https://time.geekbang.org/course/intro/138?code=AycjiiQk6uQRxnVJzBupFkrGkvZlmYELPRsZbWzaAHE=)。
|
||||
|
||||
如果面试官问你这个问题，就一定想看你知道 Nginx 服务器的一些优点吗。
|
||||
|
||||
Nginx 有以下5个优点：
|
||||
|
||||
1. 高并发、高性能（这是其他web服务器不具有的）
|
||||
2. 可扩展性好（模块化设计，第三方插件生态圈丰富）
|
||||
3. 高可靠性（可以在服务器行持续不间断的运行数年）
|
||||
4. 热部署（这个功能对于 Nginx 来说特别重要，热部署指可以在不停止 Nginx服务的情况下升级 Nginx）
|
||||
5. BSD许可证（意味着我们可以将源代码下载下来进行修改然后使用自己的版本）
|
||||
|
||||
### 5.3 Nginx 的四个主要组成部分了解吗？
|
||||
|
||||
> 这部分内容参考极客时间—[Nginx核心知识100讲的内容](https://time.geekbang.org/course/intro/138?code=AycjiiQk6uQRxnVJzBupFkrGkvZlmYELPRsZbWzaAHE=)。
|
||||
|
||||
- Nginx 二进制可执行文件：由各模块源码编译出一个文件
|
||||
- Nginx.conf 配置文件：控制Nginx 行为
|
||||
- acess.log 访问日志： 记录每一条HTTP请求信息
|
||||
- error.log 错误日志:定位问题
|
||||
Loading…
x
Reference in New Issue
Block a user