mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-20 22:17:09 +08:00
Merge pull request #289 from dongzl/master
阅读PDF 第六部分 至 第十三部分文章，修正其中一些小错误
This commit is contained in:
SnailClimb
GitHub
commit
d4fea22203
@ -112,7 +112,7 @@ Set 继承于 Collection 接口，是一个不允许出现重复元素，并且
|
||||
|
||||
[完全二叉树](https://baike.baidu.com/item/%E5%AE%8C%E5%85%A8%E4%BA%8C%E5%8F%89%E6%A0%91)（百度百科）
|
||||
|
||||
完全二叉树：叶节点只能出现在最下层和次下层，并且最下面一层的结点都集中在该层最左边的若干位置的二叉树
|
||||
完全二叉树：叶节点只能出现在最下层和次下层，并且最下面一层的结点都集中在该层最左边的若干位置的二叉树。
|
||||
* ### 3 满二叉树
|
||||
|
||||
[满二叉树](https://baike.baidu.com/item/%E6%BB%A1%E4%BA%8C%E5%8F%89%E6%A0%91)（百度百科，国内外的定义不同）
|
||||
@ -122,7 +122,7 @@ Set 继承于 Collection 接口，是一个不允许出现重复元素，并且
|
||||
|
||||
[数据结构之堆的定义](https://blog.csdn.net/qq_33186366/article/details/51876191)
|
||||
|
||||
堆是具有以下性质的完全二叉树：每个结点的值都大于或等于其左右孩子结点的值，称为大顶堆；或者每个结点的值都小于或等于其左右孩子结点的值，称为小顶堆
|
||||
堆是具有以下性质的完全二叉树：每个结点的值都大于或等于其左右孩子结点的值，称为大顶堆；或者每个结点的值都小于或等于其左右孩子结点的值，称为小顶堆。
|
||||
* ### 4 二叉查找树（BST）
|
||||
|
||||
[浅谈算法和数据结构: 七 二叉查找树](http://www.cnblogs.com/yangecnu/p/Introduce-Binary-Search-Tree.html)
|
||||
@ -131,7 +131,7 @@ Set 继承于 Collection 接口，是一个不允许出现重复元素，并且
|
||||
|
||||
1. 若任意节点的左子树不空，则左子树上所有结点的 值均小于它的根结点的值；
|
||||
2. 若任意节点的右子树不空，则右子树上所有结点的值均大于它的根结点的值；
|
||||
3. 任意节点的左、右子树也分别为二叉查找树。
|
||||
3. 任意节点的左、右子树也分别为二叉查找树；
|
||||
4. 没有键值相等的节点（no duplicate nodes）。
|
||||
|
||||
* ### 5 平衡二叉树（Self-balancing binary search tree）
|
||||
@ -144,7 +144,7 @@ Set 继承于 Collection 接口，是一个不允许出现重复元素，并且
|
||||
2. 根节点总是黑色的；
|
||||
3. 每个叶子节点都是黑色的空节点（NIL节点）；
|
||||
4. 如果节点是红色的，则它的子节点必须是黑色的（反之不一定）；
|
||||
5. 从根节点到叶节点或空子节点的每条路径，必须包含相同数目的黑色节点（即相同的黑色高度）
|
||||
5. 从根节点到叶节点或空子节点的每条路径，必须包含相同数目的黑色节点（即相同的黑色高度）。
|
||||
|
||||
- 红黑树的应用：
|
||||
|
||||
@ -166,9 +166,9 @@ Set 继承于 Collection 接口，是一个不允许出现重复元素，并且
|
||||
|
||||
[《B-树，B+树与B*树的优缺点比较》](https://blog.csdn.net/bigtree_3721/article/details/73632405)
|
||||
|
||||
B-树（或B树）是一种平衡的多路查找(又称排序)树，在文件系统中有所应用。主要用作文件的索引。其中的B就表示平衡(Balance)
|
||||
B-树（或B树）是一种平衡的多路查找（又称排序）树，在文件系统中有所应用。主要用作文件的索引。其中的B就表示平衡(Balance)
|
||||
1. B+ 树的叶子节点链表结构相比于 B- 树便于扫库，和范围检索。
|
||||
2. B+树支持range-query(区间查询)非常方便，而B树不支持。这是数据库选用B+树的最主要原因。
|
||||
2. B+树支持range-query（区间查询）非常方便，而B树不支持。这是数据库选用B+树的最主要原因。
|
||||
3. B\*树 是B+树的变体，B\*树分配新结点的概率比B+树要低，空间使用率更高；
|
||||
* ### 8 LSM 树
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@
|
||||
|
||||
### redis 简介
|
||||
|
||||
简单来说 redis 就是一个数据库，不过与传统数据库不同的是 redis 的数据是存在内存中的，所以存写速度非常快，因此 redis 被广泛应用于缓存方向。另外，redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外，redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。
|
||||
简单来说 redis 就是一个数据库，不过与传统数据库不同的是 redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向。另外，redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外，redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。
|
||||
|
||||
### 为什么要用 redis/为什么要用缓存
|
||||
|
||||
@ -84,7 +84,7 @@ String数据结构是简单的key-value类型，value其实不仅可以是String
|
||||
#### 2.Hash
|
||||
> **常用命令：** hget,hset,hgetall 等。
|
||||
|
||||
Hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。 比如我们可以Hash数据结构来存储用户信息，商品信息等等。比如下面我就用 hash 类型存放了我本人的一些信息：
|
||||
hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。 比如我们可以 hash 数据结构来存储用户信息，商品信息等等。比如下面我就用 hash 类型存放了我本人的一些信息：
|
||||
|
||||
```
|
||||
key=JavaUser293847
|
||||
@ -160,7 +160,7 @@ redis 配置文件 redis.conf 中有相关注释，我这里就不贴了，大
|
||||
1. **volatile-lru**：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
|
||||
2. **volatile-ttl**：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
|
||||
3. **volatile-random**：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
|
||||
4. **allkeys-lru**：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）.
|
||||
4. **allkeys-lru**：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
|
||||
5. **allkeys-random**：从数据集（server.db[i].dict）中任意选择数据淘汰
|
||||
6. **no-eviction**：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！
|
||||
|
||||
@ -172,7 +172,7 @@ redis 配置文件 redis.conf 中有相关注释，我这里就不贴了，大
|
||||
|
||||
很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后回复数据），或者是为了防止系统故障而将数据备份到一个远程位置。
|
||||
|
||||
Redis不同于Memcached的很重一点就是，Redis支持持久化，而且支持两种不同的持久化操作。**Redis的一种持久化方式叫快照（snapshotting，RDB）,另一种方式是只追加文件（append-only file,AOF）**.这两种方法各有千秋，下面我会详细这两种持久化方法是什么，怎么用，如何选择适合自己的持久化方法。
|
||||
Redis不同于Memcached的很重一点就是，Redis支持持久化，而且支持两种不同的持久化操作。**Redis的一种持久化方式叫快照（snapshotting，RDB），另一种方式是只追加文件（append-only file,AOF）**。这两种方法各有千秋，下面我会详细这两种持久化方法是什么，怎么用，如何选择适合自己的持久化方法。
|
||||
|
||||
**快照（snapshotting）持久化（RDB）**
|
||||
|
||||
@ -219,7 +219,7 @@ Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通
|
||||
|
||||
AOF重写可以产生一个新的AOF文件，这个新的AOF文件和原有的AOF文件所保存的数据库状态一样，但体积更小。
|
||||
|
||||
AOF重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有AOF文件进行任伺读入、分析或者写入操作。
|
||||
AOF重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有AOF文件进行任何读入、分析或者写入操作。
|
||||
|
||||
在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的AOF文件，以此来完成AOF文件重写操作
|
||||
|
||||
@ -232,7 +232,7 @@ AOF重写是一个有歧义的名字，该功能是通过读取数据库中的
|
||||
|
||||
Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。
|
||||
|
||||
在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中，事务总是具有原子性（Atomicity)、一致性(Consistency)和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）。
|
||||
在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）。
|
||||
|
||||
### 缓存雪崩和缓存穿透问题解决方案
|
||||
|
||||
|
||||
@ -78,7 +78,7 @@
|
||||
|
||||
## 1. `System.out.println(3|9)`输出什么?
|
||||
|
||||
正确答案：11.
|
||||
正确答案：11。
|
||||
|
||||
**考察知识点：&和&&；|和||**
|
||||
|
||||
@ -110,10 +110,10 @@ request.getRequestDispatcher("login_success.jsp").forward(request, response);
|
||||
|
||||
**重定向（Redirect）** 是利用服务器返回的状态吗来实现的。客户端浏览器请求服务器的时候，服务器会返回一个状态码。服务器通过HttpServletRequestResponse的setStatus(int status)方法设置状态码。如果服务器返回301或者302，则浏览器会到新的网址重新请求该资源。
|
||||
|
||||
1. **从地址栏显示来说:** forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址. redirect是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL.
|
||||
2. **从数据共享来说:** forward:转发页面和转发到的页面可以共享request里面的数据. redirect:不能共享数据.
|
||||
3. **从运用地方来说:** forward:一般用于用户登陆的时候,根据角色转发到相应的模块. redirect:一般用于用户注销登陆时返回主页面和跳转到其它的网站等
|
||||
4. **从效率来说:** forward:高. redirect:低.
|
||||
1. **从地址栏显示来说**：forward是服务器请求资源，服务器直接访问目标地址的URL，把那个URL的响应内容读取过来，然后把这些内容再发给浏览器。浏览器根本不知道服务器发送的内容从哪里来的，所以它的地址栏还是原来的地址。redirect是服务端根据逻辑，发送一个状态码，告诉浏览器重新去请求那个地址。所以地址栏显示的是新的URL。
|
||||
2. **从数据共享来说**：forward：转发页面和转发到的页面可以共享request里面的数据。redirect：不能共享数据。
|
||||
3. **从运用地方来说**：forward：一般用于用户登陆的时候，根据角色转发到相应的模块。redirect：一般用于用户注销登陆时返回主页面和跳转到其它的网站等。
|
||||
4. **从效率来说**：forward：高。redirect：低。
|
||||
|
||||
|
||||
## 3. 在浏览器中输入url地址到显示主页的过程,整个过程会使用哪些协议
|
||||
@ -382,7 +382,7 @@ TransactionDefinition 接口中定义了五个表示隔离级别的常量：
|
||||
|
||||
|
||||
|
||||
客户端发送请求-> 前端控制器 DispatcherServlet 接受客户端请求 -> 找到处理器映射 HandlerMapping 解析请求对应的 Handler-> HandlerAdapter 会根据 Handler 来调用真正的处理器开处理请求，并处理相应的业务逻辑 -> 处理器返回一个模型视图 ModelAndView -> 视图解析器进行解析 -> 返回一个视图对象->前端控制器 DispatcherServlet 渲染数据（Model）->将得到视图对象返回给用户
|
||||
客户端发送请求-> 前端控制器 DispatcherServlet 接受客户端请求 -> 找到处理器映射 HandlerMapping 解析请求对应的 Handler-> HandlerAdapter 会根据 Handler 来调用真正的处理器处理请求，并处理相应的业务逻辑 -> 处理器返回一个模型视图 ModelAndView -> 视图解析器进行解析 -> 返回一个视图对象->前端控制器 DispatcherServlet 渲染数据（Model）->将得到视图对象返回给用户
|
||||
|
||||
关于 SpringMVC 原理更多内容可以查看我的这篇文章：[SpringMVC 工作原理详解](https://mp.weixin.qq.com/s?__biz=MzU4NDQ4MzU5OA==&mid=2247484496&idx=1&sn=5472ffa687fe4a05f8900d8ee6726de4&chksm=fd985231caefdb27fc75b44ecf76b6f43e4617e0b01b3c040f8b8fab32e51dfa5118eed1d6ad&token=1990180468&lang=zh_CN#rd)
|
||||
|
||||
@ -390,7 +390,7 @@ TransactionDefinition 接口中定义了五个表示隔离级别的常量：
|
||||
|
||||
过了秋招挺长一段时间了，说实话我自己也忘了如何简要概括 Spring AOP IOC 实现原理，就在网上找了一个较为简洁的答案，下面分享给各位。
|
||||
|
||||
**IOC:** 控制反转也叫依赖注入。IOC利用java反射机制，AOP利用代理模式。IOC 概念看似很抽象，但是很容易理解。说简单点就是将对象交给容器管理，你只需要在spring配置文件中配置对应的bean以及设置相关的属性，让spring容器来生成类的实例对象以及管理对象。在spring容器启动的时候，spring会把你在配置文件中配置的bean都初始化好，然后在你需要调用的时候，就把它已经初始化好的那些bean分配给你需要调用这些bean的类。
|
||||
**IOC：** 控制反转也叫依赖注入。IOC利用java反射机制，AOP利用代理模式。IOC 概念看似很抽象，但是很容易理解。说简单点就是将对象交给容器管理，你只需要在spring配置文件中配置对应的bean以及设置相关的属性，让spring容器来生成类的实例对象以及管理对象。在spring容器启动的时候，spring会把你在配置文件中配置的bean都初始化好，然后在你需要调用的时候，就把它已经初始化好的那些bean分配给你需要调用这些bean的类。
|
||||
|
||||
**AOP：** 面向切面编程。（Aspect-Oriented Programming） 。AOP可以说是对OOP的补充和完善。OOP引入封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合。实现AOP的技术，主要分为两大类：一是采用动态代理技术，利用截取消息的方式，对该消息进行装饰，以取代原有对象行为的执行；二是采用静态织入的方式，引入特定的语法创建“方面”，从而使得编译器可以在编译期间织入有关“方面”的代码，属于静态代理。
|
||||
|
||||
@ -421,7 +421,7 @@ TransactionDefinition 接口中定义了五个表示隔离级别的常量：
|
||||
|
||||
> **先来简单说一下分布式服务：**
|
||||
|
||||
目前使用比较多的用来构建**SOA（Service Oriented Architecture面向服务体系结构）**的**分布式服务框架**是阿里巴巴开源的**Dubbo**.如果想深入了解Dubbo的可以看我写的关于Dubbo的这一篇文章：**《高性能优秀的服务框架-dubbo介绍》**：[https://juejin.im/post/5acadeb1f265da2375072f9c](https://juejin.im/post/5acadeb1f265da2375072f9c)
|
||||
目前使用比较多的用来构建**SOA（Service Oriented Architecture面向服务体系结构）**的**分布式服务框架**是阿里巴巴开源的**Dubbo**。如果想深入了解Dubbo的可以看我写的关于Dubbo的这一篇文章：**《高性能优秀的服务框架-dubbo介绍》**：[https://juejin.im/post/5acadeb1f265da2375072f9c](https://juejin.im/post/5acadeb1f265da2375072f9c)
|
||||
|
||||
> **再来谈我们的分布式消息队列：**
|
||||
|
||||
@ -464,7 +464,7 @@ TransactionDefinition 接口中定义了五个表示隔离级别的常量：
|
||||
|
||||
### 1.4 关于消息队列其他一些常见的问题展望
|
||||
|
||||
1. 引入消息队列之后如何保证高可用性
|
||||
1. 引入消息队列之后如何保证高可用性？
|
||||
2. 如何保证消息不被重复消费呢？
|
||||
3. 如何保证消息的可靠性传输（如何处理消息丢失的问题）？
|
||||
4. 我该怎么保证从消息队列里拿到的数据按顺序执行？
|
||||
@ -495,8 +495,8 @@ MyISAM更适合读密集的表，而InnoDB更适合写密集的的表。 在数
|
||||
|
||||
- **1. 是否保证线程安全：** ArrayList 和 LinkedList 都是不同步的，也就是不保证线程安全；
|
||||
- **2. 底层数据结构：** Arraylist 底层使用的是Object数组；LinkedList 底层使用的是双向链表数据结构（注意双向链表和双向循环链表的区别：）；
|
||||
- **3. 插入和删除是否受元素位置的影响：** ① **ArrayList 采用数组存储，所以插入和删除元素的时间复杂度受元素位置的影响。** 比如：执行`add(E e) `方法的时候， ArrayList 会默认在将指定的元素追加到此列表的末尾，这种情况时间复杂度就是O(1)。但是如果要在指定位置 i 插入和删除元素的话（`add(int index, E element) `）时间复杂度就为 O(n-i)。因为在进行上述操作的时候集合中第 i 和第 i 个元素之后的(n-i)个元素都要执行向后位/向前移一位的操作。 ② **LinkedList 采用链表存储，所以插入，删除元素时间复杂度不受元素位置的影响，都是近似 O（1）而数组为近似 O（n）。**
|
||||
- **4. 是否支持快速随机访问：** LinkedList 不支持高效的随机元素访问，而 ArrayList 支持。快速随机访问就是通过元素的序号快速获取元素对象(对应于`get(int index) `方法)。
|
||||
- **3. 插入和删除是否受元素位置的影响：** ① **ArrayList 采用数组存储，所以插入和删除元素的时间复杂度受元素位置的影响。** 比如：执行`add(E e) `方法的时候， ArrayList 会默认在将指定的元素追加到此列表的末尾，这种情况时间复杂度就是O(1)。但是如果要在指定位置 i 插入和删除元素的话（`add(int index, E element) `）时间复杂度就为 O(n-i)。因为在进行上述操作的时候集合中第 i 和第 i 个元素之后的(n-i)个元素都要执行向后位/向前移一位的操作。 ② **LinkedList 采用链表存储，所以插入，删除元素时间复杂度不受元素位置的影响，都是近似 O(1) 而数组为近似 O(n) 。**
|
||||
- **4. 是否支持快速随机访问：** LinkedList 不支持高效的随机元素访问，而 ArrayList 支持。快速随机访问就是通过元素的序号快速获取元素对象（对应于`get(int index) `方法）。
|
||||
- **5. 内存空间占用：** ArrayList的空 间浪费主要体现在在list列表的结尾会预留一定的容量空间，而LinkedList的空间花费则体现在它的每一个元素都需要消耗比ArrayList更多的空间（因为要存放直接后继和直接前驱以及数据）。
|
||||
|
||||
**补充内容:RandomAccess接口**
|
||||
@ -508,7 +508,7 @@ public interface RandomAccess {
|
||||
|
||||
查看源码我们发现实际上 RandomAccess 接口中什么都没有定义。所以，在我看来 RandomAccess 接口不过是一个标识罢了。标识什么？ 标识实现这个接口的类具有随机访问功能。
|
||||
|
||||
在binarySearch（）方法中，它要判断传入的list 是否RamdomAccess的实例，如果是，调用indexedBinarySearch（）方法，如果不是，那么调用iteratorBinarySearch（）方法
|
||||
在 binarySearch() 方法中，它要判断传入的 list 是否RamdomAccess的实例，如果是，调用 indexedBinarySearch() 方法，如果不是，那么调用 iteratorBinarySearch() 方法
|
||||
|
||||
```java
|
||||
public static <T>
|
||||
@ -520,7 +520,7 @@ public interface RandomAccess {
|
||||
}
|
||||
|
||||
```
|
||||
ArraysList 实现了 RandomAccess 接口， 而 LinkedList 没有实现。为什么呢？我觉得还是和底层数据结构有关！ArraysList 底层是数组，而 LinkedList 底层是链表。数组天然支持随机访问，时间复杂度为 O（1），所以称为快速随机访问。链表需要遍历到特定位置才能访问特定位置的元素，时间复杂度为 O（n），所以不支持快速随机访问。，ArraysList 实现了 RandomAccess 接口，就表明了他具有快速随机访问功能。 RandomAccess 接口只是标识，并不是说 ArraysList 实现 RandomAccess 接口才具有快速随机访问功能的！
|
||||
ArraysList 实现了 RandomAccess 接口， 而 LinkedList 没有实现。为什么呢？我觉得还是和底层数据结构有关！ArraysList 底层是数组，而 LinkedList 底层是链表。数组天然支持随机访问，时间复杂度为 O(1) ，所以称为快速随机访问。链表需要遍历到特定位置才能访问特定位置的元素，时间复杂度为 O(n) ，所以不支持快速随机访问。，ArraysList 实现了 RandomAccess 接口，就表明了他具有快速随机访问功能。 RandomAccess 接口只是标识，并不是说 ArraysList 实现 RandomAccess 接口才具有快速随机访问功能的！
|
||||
|
||||
|
||||
|
||||
@ -688,7 +688,7 @@ hashCode() 的作用是获取哈希码，也称为散列码；它实际上是返
|
||||
#### 1.2.3 hashCode()与equals()的相关规定
|
||||
|
||||
1. 如果两个对象相等，则hashcode一定也是相同的
|
||||
2. 两个对象相等,对两个对象分别调用equals方法都返回true
|
||||
2. 两个对象相等，对两个对象分别调用equals方法都返回true
|
||||
3. 两个对象有相同的hashcode值，它们也不一定是相等的
|
||||
4. **因此，equals方法被覆盖过，则hashCode方法也必须被覆盖**
|
||||
5. hashCode()的默认行为是对堆上的对象产生独特值。如果没有重写hashCode()，则该class的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）
|
||||
@ -737,7 +737,7 @@ public class test1 {
|
||||
|
||||
**说明：**
|
||||
|
||||
- String中的equals方法是被重写过的，因为object的equals方法是比较的对象的内存地址，而String的equals方法比较的是对象的值。
|
||||
- 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 这俩兄弟在一般只要面试中问到集合相关的问题就一定会被问到，所以各位务必引起重视！
|
||||
@ -749,7 +749,7 @@ public class test1 {
|
||||
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(同一把锁)** : s使用 synchronized 来保证线程安全，效率非常低下。当一个线程访问同步方法时，其他线程也访问同步方法，可能会进入阻塞或轮询状态，如使用 put 添加元素，另一个线程不能使用 put 添加元素，也不能使用 get，竞争会越来越激烈效率越低。
|
||||
- **实现线程安全的方式（重要）：** ① **在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，竞争会越来越激烈效率越低。
|
||||
|
||||
**两者的对比图：**
|
||||
|
||||
@ -787,29 +787,29 @@ ConcurrentHashMap取消了Segment分段锁，采用CAS和synchronized来保证
|
||||
|
||||
synchronized只锁定当前链表或红黑二叉树的首节点，这样只要hash不冲突，就不会产生并发，效率又提升N倍。
|
||||
|
||||
## 3 谈谈 synchronized 和 ReenTrantLock 的区别
|
||||
## 3 谈谈 synchronized 和 ReentrantLock 的区别
|
||||
|
||||
**① 两者都是可重入锁**
|
||||
|
||||
两者都是可重入锁。“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。
|
||||
|
||||
**② synchronized 依赖于 JVM 而 ReenTrantLock 依赖于 API**
|
||||
**② synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API**
|
||||
|
||||
synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReenTrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。
|
||||
synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReentrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。
|
||||
|
||||
**③ ReenTrantLock 比 synchronized 增加了一些高级功能**
|
||||
**③ ReentrantLock 比 synchronized 增加了一些高级功能**
|
||||
|
||||
相比synchronized，ReenTrantLock增加了一些高级功能。主要来说主要有三点：**①等待可中断；②可实现公平锁；③可实现选择性通知（锁可以绑定多个条件）**
|
||||
相比synchronized，ReentrantLock增加了一些高级功能。主要来说主要有三点：**①等待可中断；②可实现公平锁；③可实现选择性通知（锁可以绑定多个条件）**
|
||||
|
||||
- **ReenTrantLock提供了一种能够中断等待锁的线程的机制**，通过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
|
||||
- **ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。** ReenTrantLock默认情况是非公平的，可以通过 ReenTrantLock类的`ReentrantLock(boolean fair)`构造方法来制定是否是公平的。
|
||||
- **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是一个不错的选择。
|
||||
如果你想使用上述功能，那么选择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操作。
|
||||
在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 线程池了解吗?
|
||||
@ -837,9 +837,9 @@ synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团
|
||||
#### 各种线程池的适用场景介绍
|
||||
|
||||
- **FixedThreadPool：** 适用于为了满足资源管理需求，而需要限制当前线程数量的应用场景。它适用于负载比较重的服务器；
|
||||
- **SingleThreadExecutor：** 适用于需要保证顺序地执行各个任务并且在任意时间点，不会有多个线程是活动的应用场景。
|
||||
- **SingleThreadExecutor：** 适用于需要保证顺序地执行各个任务并且在任意时间点，不会有多个线程是活动的应用场景；
|
||||
- **CachedThreadPool：** 适用于执行很多的短期异步任务的小程序，或者是负载较轻的服务器；
|
||||
- **ScheduledThreadPoolExecutor：** 适用于需要多个后台执行周期任务，同时为了满足资源管理需求而需要限制后台线程的数量的应用场景，
|
||||
- **ScheduledThreadPoolExecutor：** 适用于需要多个后台执行周期任务，同时为了满足资源管理需求而需要限制后台线程的数量的应用场景；
|
||||
- **SingleThreadScheduledExecutor：** 适用于需要单个后台线程执行周期任务，同时保证顺序地执行各个任务的应用场景。
|
||||
|
||||
### 4.3 创建的线程池的方式
|
||||
@ -920,7 +920,7 @@ Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（I
|
||||
|
||||
Nginx支持的weight轮询（默认）、ip_hash、fair、url_hash这四种负载均衡调度算法，感兴趣的可以自行查阅。
|
||||
|
||||
负载均衡相比于反向代理更侧重的时将请求分担到多台服务器上去，所以谈论负载均衡只有在提供某服务的服务器大于两台时才有意义。
|
||||
负载均衡相比于反向代理更侧重的是将请求分担到多台服务器上去，所以谈论负载均衡只有在提供某服务的服务器大于两台时才有意义。
|
||||
|
||||
#### 动静分离
|
||||
|
||||
@ -945,6 +945,6 @@ Nginx 有以下5个优点：
|
||||
> 这部分内容参考极客时间—[Nginx核心知识100讲的内容](https://time.geekbang.org/course/intro/138?code=AycjiiQk6uQRxnVJzBupFkrGkvZlmYELPRsZbWzaAHE=)。
|
||||
|
||||
- Nginx 二进制可执行文件：由各模块源码编译出一个文件
|
||||
- Nginx.conf 配置文件：控制Nginx 行为
|
||||
- nginx.conf 配置文件：控制Nginx 行为
|
||||
- acess.log 访问日志： 记录每一条HTTP请求信息
|
||||
- error.log 错误日志:定位问题
|
||||
- error.log 错误日志：定位问题
|
||||
|
||||
@ -44,7 +44,7 @@ Dubbo 是由阿里开源，后来加入了 Apache 。正式由于 Dubbo 的出
|
||||
|
||||
**什么是 RPC？**
|
||||
|
||||
RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。比如两个不同的服务A,B部署在两台不同的机器上，那么服务 A 如果想要调用服务 B 中的某个方法该怎么办呢？使用 HTTP请求 当然可以，但是可能会比较慢而且一些优化做的并不好。 RPC 的出现就是为了解决这个问题。
|
||||
RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。比如两个不同的服务 A、B 部署在两台不同的机器上，那么服务 A 如果想要调用服务 B 中的某个方法该怎么办呢？使用 HTTP请求 当然可以，但是可能会比较慢而且一些优化做的并不好。 RPC 的出现就是为了解决这个问题。
|
||||
|
||||
**RPC原理是什么？**
|
||||
|
||||
@ -81,10 +81,10 @@ Dubbo 的诞生和 SOA 分布式架构的流行有着莫大的关系。SOA 面
|
||||
|
||||
我觉得主要可以从 Dubbo 提供的下面四点特性来说为什么要用 Dubbo：
|
||||
|
||||
1. **负载均衡**——同一个服务部署在不同的机器时该调用那一台机器上的服务
|
||||
1. **负载均衡**——同一个服务部署在不同的机器时该调用那一台机器上的服务。
|
||||
2. **服务调用链路生成**——随着系统的发展，服务越来越多，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。Dubbo 可以为我们解决服务之间互相是如何调用的。
|
||||
3. **服务访问压力以及时长统计、资源调度和治理**——基于访问压力实时管理集群容量，提高集群利用率。
|
||||
4. **服务降级**——某个服务挂掉之后调用备用服务
|
||||
4. **服务降级**——某个服务挂掉之后调用备用服务。
|
||||
|
||||
另外，Dubbo 除了能够应用在分布式系统中，也可以应用在现在比较火的微服务系统中。不过，由于 Spring Cloud 在微服务中应用更加广泛，所以，我觉得一般我们提 Dubbo 的话，大部分是分布式系统的情况。
|
||||
|
||||
@ -98,7 +98,7 @@ Dubbo 的诞生和 SOA 分布式架构的流行有着莫大的关系。SOA 面
|
||||
|
||||
从开发角度来讲单体应用的代码都集中在一起，而分布式系统的代码根据业务被拆分。所以，每个团队可以负责一个服务的开发，这样提升了开发效率。另外，代码根据业务拆分之后更加便于维护和扩展。
|
||||
|
||||
另外，我觉得将系统拆分成分布式之后不光便于系统扩展和维护，更能提高整个系统的性能。你想一想嘛?把整个系统拆分成不同的服务/系统，然后每个服务/系统 单独部署在一台服务器上，是不是很大程度上提高了系统性能呢？
|
||||
另外，我觉得将系统拆分成分布式之后不光便于系统扩展和维护，更能提高整个系统的性能。你想一想嘛？把整个系统拆分成不同的服务/系统，然后每个服务/系统 单独部署在一台服务器上，是不是很大程度上提高了系统性能呢？
|
||||
|
||||
## 二 Dubbo 的架构
|
||||
|
||||
@ -156,7 +156,7 @@ Dubbo 的诞生和 SOA 分布式架构的流行有着莫大的关系。SOA 面
|
||||
- 第七层：**protocol层**，远程调用层，封装rpc调用
|
||||
- 第八层：**exchange层**，信息交换层，封装请求响应模式，同步转异步
|
||||
- 第九层：**transport层**，网络传输层，抽象mina和netty为统一接口
|
||||
- 第十层：**serialize层**，数据序列化层。网络传输需要。
|
||||
- 第十层：**serialize层**，数据序列化层，网络传输需要
|
||||
|
||||
|
||||
## 三 Dubbo 的负载均衡策略
|
||||
@ -165,7 +165,7 @@ Dubbo 的诞生和 SOA 分布式架构的流行有着莫大的关系。SOA 面
|
||||
|
||||
**先来个官方的解释。**
|
||||
|
||||
> 维基百科对负载均衡的定义：负载均衡改善了跨多个计算资源（例如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动的的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载平衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载平衡通常涉及专用软件或硬件
|
||||
> 维基百科对负载均衡的定义：负载均衡改善了跨多个计算资源（例如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动的的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载平衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载平衡通常涉及专用软件或硬件。
|
||||
|
||||
**上面讲的大家可能不太好理解，再用通俗的话给大家说一下。**
|
||||
|
||||
|
||||
@ -75,7 +75,7 @@
|
||||
|
||||
#### 4.1.1 JMS 简介
|
||||
|
||||
JMS（JAVA Message Service,java消息服务）是java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。**JMS（JAVA Message Service,Java消息服务）API是一个消息服务的标准或者说是规范**，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。
|
||||
JMS（JAVA Message Service,java消息服务）是java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。**JMS（JAVA Message Service，Java消息服务）API是一个消息服务的标准或者说是规范**，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。
|
||||
|
||||
**ActiveMQ 就是基于 JMS 规范实现的。**
|
||||
|
||||
@ -84,12 +84,16 @@
|
||||
①点到点（P2P）模型
|
||||
|
||||
|
||||
使用**队列（Queue）**作为消息通信载体；满足**生产者与消费者模式**，一条消息只能被一个消费者使用，未被消费的消息在队列中保留直到被消费或超时。比如：我们生产者发送100条消息的话，两个消费者来消费一般情况下两个消费者会按照消息发送的顺序各自消费一半（也就是你一个我一个的消费。）
|
||||
|
||||
|
||||
使用**队列（Queue）**作为消息通信载体；满足**生产者与消费者模式**，一条消息只能被一个消费者使用，未被消费的消息在队列中保留直到被消费或超时。比如：我们生产者发送100条消息的话，两个消费者来消费一般情况下两个消费者会按照消息发送的顺序各自消费一半（也就是你一个我一个的消费。）
|
||||
|
||||
② 发布/订阅（Pub/Sub）模型
|
||||
|
||||
|
||||
发布订阅模型（Pub/Sub） 使用**主题（Topic）**作为消息通信载体，类似于**广播模式**；发布者发布一条消息，该消息通过主题传递给所有的订阅者，**在一条消息广播之后才订阅的用户则是收不到该条消息的**。
|
||||
|
||||
|
||||
发布订阅模型（Pub/Sub） 使用**主题（Topic）**作为消息通信载体，类似于**广播模式**；发布者发布一条消息，该消息通过主题传递给所有的订阅者，**在一条消息广播之后才订阅的用户则是收不到该条消息的**。
|
||||
|
||||
#### 4.1.3 JMS 五种不同的消息正文格式
|
||||
|
||||
@ -104,7 +108,7 @@
|
||||
|
||||
### 4.2 AMQP
|
||||
|
||||
AMQP，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准 **高级消息队列协议**（二进制应用层协议），是应用层协议的一个开放标准,为面向消息的中间件设计，兼容 JMS。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件同产品，不同的开发语言等条件的限制。
|
||||
AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准 **高级消息队列协议**（二进制应用层协议），是应用层协议的一个开放标准,为面向消息的中间件设计，兼容 JMS。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件同产品，不同的开发语言等条件的限制。
|
||||
|
||||
**RabbitMQ 就是基于 AMQP 协议实现的。**
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user