From 97c8e501fd1dde4941ed9db69bdb960df762a4c5 Mon Sep 17 00:00:00 2001 From: youthlql <1826692270@qq.com> Date: Wed, 22 Dec 2021 23:07:57 +0800 Subject: [PATCH] =?UTF-8?q?jsd=20cdn=20=E5=A4=A7=E9=99=86=E8=8A=82?= =?UTF-8?q?=E7=82=B9=E9=80=90=E6=AD=A5=E8=A2=AB=E5=9B=BD=E5=86=85=E5=B0=81?= =?UTF-8?q?=E7=A6=81=EF=BC=8C=E7=8E=B0=E6=9B=B4=E6=8D=A2=E5=9B=BE=E5=BA=8A?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/Apollo/Apollo简单入门.md | 120 +++++++++--------- docs/Computer_NetWork/计算机网络-总结.md | 6 +- docs/Computer_NetWork/计算机网络-概述.md | 110 ++++++++-------- docs/ElasticSearch/ElasticSearch-入门.md | 10 +- docs/ElasticSearch/ElasticSearch-进阶.md | 2 +- .../JVM系列-第10章-垃圾回收概述和相关算法.md | 68 +++++----- docs/JVM/JVM系列-第11章-垃圾回收相关概念.md | 28 ++-- docs/JVM/JVM系列-第12章-垃圾回收器.md | 88 ++++++------- docs/JVM/JVM系列-第1章-JVM与Java体系结构.md | 34 ++--- docs/JVM/JVM系列-第2章-类加载子系统.md | 48 +++---- docs/JVM/JVM系列-第3章-运行时数据区.md | 28 ++-- docs/JVM/JVM系列-第4章-虚拟机栈.md | 84 ++++++------ docs/JVM/JVM系列-第5章-堆.md | 50 ++++---- docs/JVM/JVM系列-第6章-方法区.md | 82 ++++++------ ...列-第7章-对象的实例化内存布局与访问定位.md | 14 +- docs/JVM/JVM系列-第8章-执行引擎.md | 32 ++--- ...JVM系列-第9章-StringTable(字符串常量池).md | 48 +++---- docs/Java/Basis/Java8新特性.md | 12 +- docs/Java/Basis/泛型.md | 6 +- docs/Java/collection/HashMap-JDK7源码讲解.md | 34 ++--- .../HashMap-JDK8源码讲解及常见面试题.md | 8 +- .../Java并发体系-第一阶段-多线程基础知识.md | 20 +-- .../Java并发体系-第三阶段-JUC并发包-[1].md | 4 +- .../Java并发体系-第三阶段-JUC并发包-[2].md | 8 +- .../Java并发体系-第二阶段-锁与同步-[1].md | 32 ++--- .../Java并发体系-第二阶段-锁与同步-[2].md | 12 +- .../Java并发体系-第二阶段-锁与同步-[3].md | 28 ++-- .../Java并发体系-第四阶段-AQS源码解读-[1].md | 24 ++-- 28 files changed, 520 insertions(+), 520 deletions(-) diff --git a/docs/Apollo/Apollo简单入门.md b/docs/Apollo/Apollo简单入门.md index b1063fe..1b86adf 100644 --- a/docs/Apollo/Apollo简单入门.md +++ b/docs/Apollo/Apollo简单入门.md @@ -8,7 +8,7 @@ categories: - Apollo keywords: Apollo，配置中心。 description: Apollo简单入门及和SpringBoot集成。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.2.0/Apollo/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.9/Apollo/logo.png' abbrlink: 10d32fba date: 2020-12-29 11:31:58 --- @@ -76,7 +76,7 @@ date: 2020-12-29 11:31:58 不过，解决一个问题的同时，往往会诞生出很多新的问题，所以微服务化的过程中伴随着很多的挑战，其中一个挑战就是有关服务（应用）配置的。当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移（分割），这样配置就分散了，不仅如此，分散中还包含着冗余，如下图： - + 配置中心将配置从应用中剥离出来，统一管理，优雅的解决了配置的动态变更、持久化、运维成本等问题。 @@ -86,7 +86,7 @@ date: 2020-12-29 11:31:58 在系统架构中，配置中心是整个微服务基础架构体系中的一个组件，如下图，它的功能看上去并不起眼，无非就是配置的管理和存取，但它是整个微服务架构中不可或缺的一环。 - + @@ -171,7 +171,7 @@ Apollo简介 ### Apollo简介 - + **Apollo - A reliable configuration management system** @@ -221,7 +221,7 @@ Apollo快速入门 ### 执行流程 - + 操作流程如下： @@ -262,7 +262,7 @@ Apollo的表结构对`timestamp`使用了多个default声明，所以需要5.6.5 2. 打开1.3发布链接，下载必须的安装包：[https://github.com/ctripcorp/apollo/releases/tag/v1.3.0](https://github.com/ctripcorp/apollo/releases/tag/v1.3.0)。三个都要下 - + 解压安装包后将apollo-configservice-1.3.0.jar, apollo-adminservice-1.3.0.jar, apollo-portal-1.3.0.jar放置于apollo目录下 @@ -349,11 +349,11 @@ Apollo服务端共需要两个数据库：`ApolloPortalDB`和`ApolloConfigDB`， 1. 也可以使用提供的runApollo.bat快速启动三个服务（修改数据库连接地址，数据库以及密码） - + 这里面是一个很简单的脚本 - + @@ -385,29 +385,29 @@ start "ApolloPortal" java -Xms256m -Xmx256m -Dapollo_profile=github,auth -Ddev_m 1. 打开[apollo](http://localhost:8070/) ：新建项目apollo-quickstart - + 2. 新建配置项sms.enable - + - + 确认提交配置项 - + -![image-20201228102339176](https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.2.0/Apollo/Simple_Introduction/0012.png) +![image-20201228102339176](https://unpkg.zhimg.com/youthlql@1.0.9/Apollo/Simple_Introduction/0012.png) 3. 发布配置项 - + #### 应用读取配置 @@ -485,7 +485,7 @@ public class GetConfigTest { -Dapp.id=apollo-quickstart -Denv=DEV -Ddev_meta=http://localhost:8080 - + 运行GetConfigTest，打开控制台，观察输出结果 @@ -523,19 +523,19 @@ sma.enable: true 2. 运行GetConfigTest观察输出结果 - + 3. 在Apollo管理界面修改配置项 - + 4. 发布配置 - + 5. 在控制台查看详细情况：可以看到程序获取的sms.enable的值已由false变成了修改后的true - + @@ -546,7 +546,7 @@ Apollo应用 下图是Apollo架构模块的概览 - + #### 各模块职责 @@ -601,7 +601,7 @@ Apollo应用 它们的关系如下图所示： - + @@ -615,15 +615,15 @@ apollo 默认部门有两个。要增加自己的部门，可在系统参数中 * 进入系统参数设置 - + -![image-20201228103939300](https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.2.0/Apollo/Simple_Introduction/0022.png) +![image-20201228103939300](https://unpkg.zhimg.com/youthlql@1.0.9/Apollo/Simple_Introduction/0022.png) * 输入key查询已存在的部门设置：organizations - + * 修改value值来添加新部门，下面添加一个微服务部门： @@ -639,11 +639,11 @@ apollo默认提供一个超级管理员: apollo，可以自行添加用户 * 新建用户张三 - + - + #### 创建项目 @@ -661,7 +661,7 @@ apollo默认提供一个超级管理员: apollo，可以自行添加用户 * 应用名称：应用名，仅用于界面展示 * 应用负责人：选择的人默认会成为该项目的管理员，具备项目权限管理、集群创建、Namespace创建等权限 - + 4. 点击提交,创建成功后，会自动跳转到项目首页 @@ -671,7 +671,7 @@ apollo默认提供一个超级管理员: apollo，可以自行添加用户 * 使用管理员apollo将指定项目授权给用户张三 - + * 将修改和发布权限都授权给张三 @@ -731,7 +731,7 @@ Namespace作为配置的分类，可当成一个配置文件。 进入项目首页，点击左下脚的“添加Namespace”，共包括两项：关联公共Namespace和创建Namespace，这里选择“创建Namespace” - + 2. 添加配置项 @@ -758,11 +758,11 @@ Namespace作为配置的分类，可当成一个配置文件。 进入common-template项目管理页面：[http://localhost:8070/config.html?#/appid=common-template](http://localhost:8070/config.html?#/appid=common-template) - + - + 1. 添加配置项并发布 @@ -786,11 +786,11 @@ Namespace作为配置的分类，可当成一个配置文件。 2. 点击左侧的添加Namespace 3. 添加Namespace - + 4. 根据需求可以覆盖引入公共Namespace中的配置，下面以覆盖server.servlet.context-path为例 - + 5. 修改server.servlet.context-path为：/account-service 6. 发布修改的配置项 @@ -806,15 +806,15 @@ Namespace作为配置的分类，可当成一个配置文件。 1. 点击页面左侧的“添加集群”按钮 2. 输入集群名称SHAJQ，选择环境并提交：添加上海金桥数据中心为例 - + -![image-20201228112150602](https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.2.0/Apollo/Simple_Introduction/0034.png) +![image-20201228112150602](https://unpkg.zhimg.com/youthlql@1.0.9/Apollo/Simple_Introduction/0034.png) 3. 切换到对应的集群，修改配置并发布即可 - + #### 同步集群配置 @@ -827,19 +827,19 @@ Namespace作为配置的分类，可当成一个配置文件。 * 展开要同步的Namespace，点击同步配置 - + - ![image-20201228112603903](https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.2.0/Apollo/Simple_Introduction/0037.png) + ![image-20201228112603903](https://unpkg.zhimg.com/youthlql@1.0.9/Apollo/Simple_Introduction/0037.png) * 选择同步到的新集群，再选择要同步的配置 - + * 同步完成后，切换到SHAJQ集群，发布配置 - + #### 读取配置 @@ -863,7 +863,7 @@ Namespace作为配置的分类，可当成一个配置文件。 在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。下面我们简要看一下这块是怎么设计实现的。 - + 上图简要描述了配置发布的主要过程： @@ -890,7 +890,7 @@ Admin Service在配置发布后，需要通知所有的Config Service有配置 SELECT * FROM ApolloConfigDB.ReleaseMessage ``` - + @@ -1012,7 +1012,7 @@ Admin Service在配置发布后，需要通知所有的Config Service有配置 4. NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端 - + #### Config Service通知客户端 @@ -1268,7 +1268,7 @@ Apollo客户端会把从服务端获取到的配置在本地文件系统缓存 -Denv=DEV -Dapollo.cacheDir=/opt/data/apollo-config -Dapollo.cluster=DEFAULTbash ``` - + @@ -1366,11 +1366,11 @@ public class AccountApplication { 2. spring-http命名空间在之前已通过关联公共命名空间添加好了，现在来添加spring-boot-druid命名空间 - + 3. 添加本地文件中的配置到对应的命名空间，然后发布配置 - + 4. 在account-service/src/main/resources/application.properties中配置apollo.bootstrap.namespaces需要引入的命名空间(上面写过) @@ -1458,7 +1458,7 @@ public class AccountController { * 访问[http://127.0.0.1:63000/account-service/db-url](http://127.0.0.1:63000/account-service/db-url)，显示结果 - + #### 创建其它项目 @@ -1474,7 +1474,7 @@ public class AccountController { 具体如下图所示： - + 下面以添加生产环境部署为例 @@ -1523,7 +1523,7 @@ UPDATE ServerConfig SET `Value` = "http://localhost:8081/eureka/" WHERE `key` = 服务配置项统一存储在ApolloPortalDB.ServerConfig表中，可以通过`管理员工具 - 系统参数`页面进行配置：apollo.portal.envs - 可支持的环境列表 - + 默认值是dev，如果portal需要管理多个环境的话，以逗号分隔即可（大小写不敏感），如： @@ -1556,7 +1556,7 @@ Apollo Portal需要在不同的环境访问不同的meta service(apollo-configse 1. 启动之后，点击account-service服务配置后会提示环境缺失，此时需要补全上边新增生产环境的配置 - + 3. 点击左下方的补缺环境 @@ -1564,7 +1564,7 @@ Apollo Portal需要在不同的环境访问不同的meta service(apollo-configse 4. 补缺过生产环境后，切换到PRO环境后会提示有Namespace缺失，点击补缺 - + 5. 从dev环境同步配置到pro @@ -1610,7 +1610,7 @@ apollo-quickstart项目有两个客户端： 1. 172.16.0.160 2. 172.16.0.170 - + **灰度目标** @@ -1626,7 +1626,7 @@ apollo-quickstart项目有两个客户端： 2. 点击确定后，灰度版本就创建成功了，页面会自动切换到`灰度版本`Tab - + #### 灰度配置 @@ -1634,17 +1634,17 @@ apollo-quickstart项目有两个客户端： 2. 在弹出框中填入要灰度的值：3000，点击提交 - + #### 配置灰度规则 1. 切换到`灰度规则`Tab，点击`新增规则`按钮 - + 2. 在弹出框中`灰度的IP`下拉框会默认展示当前使用配置的机器列表，选择我们要灰度的IP，点击完成 - + 如果下拉框中没找到需要的IP，说明机器还没从Apollo取过配置，可以点击手动输入IP来输入，输入完后点击添加按钮 @@ -1674,11 +1674,11 @@ vm options: `-Dapp.id=apollo-quickstart -Denv=DEV -Ddev_meta=http://localhost:80 } ``` - + 2. 切换到`配置`Tab，再次检查灰度的配置部分，如果没有问题，点击`灰度发布` - + 3. 在弹出框中可以看到主版本的值是2000，灰度版本即将发布的值是3000。填入其它信息后，点击发布 @@ -1686,9 +1686,9 @@ vm options: `-Dapp.id=apollo-quickstart -Denv=DEV -Ddev_meta=http://localhost:80 4. 发布后，切换到`灰度实例列表`Tab，就能看到172.16.0.160已经使用了灰度发布的值 - + - + diff --git a/docs/Computer_NetWork/计算机网络-总结.md b/docs/Computer_NetWork/计算机网络-总结.md index d7afb88..28b0870 100644 --- a/docs/Computer_NetWork/计算机网络-总结.md +++ b/docs/Computer_NetWork/计算机网络-总结.md @@ -7,7 +7,7 @@ categories: - 计算机网络 keywords: 计算机网络，计网，面试 description: 计算机网络-总结篇，可以用来期末复习，校招面试等。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/computer_network/logo.jpg' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/computer_network/logo.jpg' abbrlink: 3905e6f8 date: 2020-04-16 17:21:58 --- @@ -185,7 +185,7 @@ https://blog.csdn.net/iispring/article/details/51615631 ## 区别+应用场景 - + **总结：** @@ -300,7 +300,7 @@ TCP通过三次握手建立可靠连接 在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。 - + diff --git a/docs/Computer_NetWork/计算机网络-概述.md b/docs/Computer_NetWork/计算机网络-概述.md index 0d17d5a..260db12 100644 --- a/docs/Computer_NetWork/计算机网络-概述.md +++ b/docs/Computer_NetWork/计算机网络-概述.md @@ -6,7 +6,7 @@ categories: - 计算机网络 keywords: 计算机网络，计网 description: 计算机网络-概述篇。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/computer_network/logo.jpg' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/computer_network/logo.jpg' abbrlink: be54bfd5 date: 2021-04-03 14:21:58 --- @@ -30,15 +30,15 @@ date: 2021-04-03 14:21:58 网络：网络（Network）由若干**结点（Node）**和连接这些结点的**链路（Link）**组成。 - + 互联网（或互连网）：多个网络通过路由器互连起来，这样就构成了一个覆盖范围更大的网络，即互连网（互联网）。因此，互联网又称为“网络的网络（Network of Networks）”。 - + 因特网：因特网（Internet）是世界上最大的互连网络（用户数以亿计，互连的网络数以百万计）。 - + @@ -52,13 +52,13 @@ date: 2021-04-03 14:21:58 ### 因特网发展的三个阶段 - + **因特网服务提供者`ISP`(`I`nternet `S`ervice `P`rovider)** - + > Q：普通用户是如何接入到因特网的呢？ > @@ -71,13 +71,13 @@ date: 2021-04-03 14:21:58 **中国的三大`ISP`：中国电信，中国联通，中国移动** - + **基于ISP的三层结构的因特网** - + 1、图中红线部分是两个私人用户进行通信的大致链路，可以看到需要经过多个ISP层级 @@ -100,7 +100,7 @@ date: 2021-04-03 14:21:58 * 因特网工程部IETF，负责研究中短期工程问题，主要针对协议的开发和标准化； * 因特网研究部IRTF，从事理论方面的研究和开发一些需要长期考虑的问题。 - + * 制订因特网的正式标准要经过一下**4个阶段**： @@ -124,7 +124,7 @@ date: 2021-04-03 14:21:58 由**大量网络**和连接这些网络的**路由器**组成。这部分是**为边缘部分提供服务**的（提供连通性和交换）。 - + 1. 路由器是一种专用计算机，但我们不称它为主机，路由器是实现分组交换的关键构建，其任务是转发收到的分组，这是网络核心最重要的部分。 @@ -142,12 +142,12 @@ date: 2021-04-03 14:21:58 ### 电路交换 - + 1. 传统两两相连的方式，当电话数量很多时，电话线也很多，就很不方便 2. 所以要使得每一部电话能够很方便地和另一部电话进行通信，就应该使用一个**中间设备**将这些电话连接起来，这个中间设备就是**电话交换机** - + * 电话交换机接通电话线的方式称为电路交换； @@ -161,7 +161,7 @@ date: 2021-04-03 14:21:58 3、释放连接（归还通信资源） - + 1. 当使用电路交换来传送计算机数据时，其线路的传输效率往往很低。这是因为计算机数据是突发式地出现在传输线路上的，而不是像打电话一样一直占用着通信资源。 2. 试想一下这种情况，当用户正在输入和编辑一份待传输的文件时，用户所占用的通信资源暂时未被利用，该通信资源也不能被其它用户利用，宝贵的通信线路资源白白被浪费了 @@ -169,7 +169,7 @@ date: 2021-04-03 14:21:58 ### 分组交换 - + 1. 通常我们把表示该消息的整块数据成为一个**报文**。 2. 在发送报文之前，先把较长的报文划分成一个个更小的等长数据段，在每一个数据段前面。加上一些由必要的控制信息组成的首部后，就构成一个分组，也可简称为“包”，相应地，首部也可称为“包头”。首部起到了很大的作用，首先首部中肯定包含了分组的目的地址，否则分组传输路径中的各分组交换机（也就是个路由器）就不知道如何转发分组了 @@ -212,7 +212,7 @@ date: 2021-04-03 14:21:58 假设A，B，C，D是分组传输路径所要经过的4个结点交换机，纵坐标为时间 - + @@ -232,7 +232,7 @@ date: 2021-04-03 14:21:58 * 可以随时发送分组，而不需要事先建立连接。构成原始报文的**一个个分组**，**依次**在各结点交换机上存储转发。各结点交换机在发送分组的同时，还缓存接收到的分组。 * **构成原始报文的一个个分组**，在各结点交换机上进行存储转发，相比报文交换，减少了转发时延，还可以避免过长的报文长时间占用链路，同时也有利于进行差错控制。 - + @@ -249,7 +249,7 @@ date: 2021-04-03 14:21:58 * 计算机网络所连接的硬件，并不限于一般的计算机，而是包括了智能手机等智能硬件。 * 计算机网络并非专门用来传送数据，而是能够支持很多种的应用（包括今后可能出现的各种应用）。 - + 上图所示的各终端机只是具有显示和输入设备的终端，而并不是自治的计算机，所以上图并不是计算机网络，只是一个运行分时系统的大型机系统。 @@ -293,7 +293,7 @@ date: 2021-04-03 14:21:58 * 总线型网络 - + 优点：建网容易，增减节点方便，节省线路 @@ -301,7 +301,7 @@ date: 2021-04-03 14:21:58 * 星型网络 - + 星型网络图中的中央设备现在一般是交换机或路由器， @@ -313,13 +313,13 @@ date: 2021-04-03 14:21:58 * 环形网络 - + 环中信号是单向传输的 * 网状型网络 - + 一般情况下，每个节点至少由两条路径与其他节点相连，多用在广域网中 @@ -333,15 +333,15 @@ date: 2021-04-03 14:21:58 ### 速率 - + ### 带宽 - + ### 吞吐量 - + 带宽1 Gb/s的以太网，代表其额定速率是1 Gb/s，这个数值也是该以太网的吞吐量的上限值。实际上，对于带宽1 Gb/s的以太网，可能实际吞吐量只有 700 Mb/s，甚至更低。 @@ -361,33 +361,33 @@ date: 2021-04-03 14:21:58 网卡的发送速率，信道带宽，交换机的接口速率，它们共同决定着主机的发送速率。 - + 当处理时延忽略不计时，发送时延和传播时延谁占主导，要具体情况具体分析 - + ### 时延带宽积 - + ### 往返时间 - + ### 利用率 - + ### 丢包率 - + @@ -397,7 +397,7 @@ date: 2021-04-03 14:21:58 ### 常见的计算机网络体系结构 - + 1、如今用的最多的是TCP/IP体系结构，现今规模最大的、覆盖全球的、基于TCP/IP的互联网并未使用OSI标准。TCP/IP体系结构相当于将OSI体系结构的物理层和数据链路层合并为了网络接口层，并去掉了会话层和表示层。 @@ -405,7 +405,7 @@ date: 2021-04-03 14:21:58 - + 1、在用户主机的操作系统中，通常都带有符合TCP/IP体系结构标准的TCP/IP协议族。而用于网络互连的路由器中，也带有符合TCP/IP体系结构标准的TCP/IP协议族。只不过路由器一般只包含网络接口层和网际层。 @@ -435,7 +435,7 @@ date: 2021-04-03 14:21:58 - + @@ -443,11 +443,11 @@ date: 2021-04-03 14:21:58 ### 分层的必要性 - + **物理层问题** - + @@ -455,7 +455,7 @@ date: 2021-04-03 14:21:58 **数据链路层问题** - + 1、如图所示，主机A要给主机C发送数据。 @@ -479,7 +479,7 @@ A：也就是需要解决分组的封装格式问题 Q：另外对于总线型的网络，还会出现下面这种典型的问题 - + @@ -493,7 +493,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 - + @@ -503,13 +503,13 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 - 引出了我们如何标识与网络通信相关的引用进程，进而解决进程之间基于网络通信的问题。 - + **应用层问题** - + @@ -517,7 +517,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 - + ### 分层思想举例 @@ -525,7 +525,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 假设网络拓扑如下所示 - + @@ -533,7 +533,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 主机和Web服务器之间基于网络的通信，实际上是主机中的浏览器应用进程与Web服务器中的Web服务器应用进程之间基于网络的通信 - + @@ -545,7 +545,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 - 应用层将HTTP请求报文交付给运输层处理 - + @@ -559,7 +559,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 - 运输层将TCP报文段交付给网络层处理 - + @@ -571,7 +571,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 - 网络层将IP数据报交付给数据链路层处理 - + @@ -589,7 +589,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 - + @@ -599,7 +599,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 * 前导码的作用是为了让目的主机做好接收帧的准备 * 物理层将装有前导码的比特流变换成相应的信号发送给传输媒体 - + @@ -607,7 +607,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 - 信号通过传输媒体到达路由器 - + @@ -646,7 +646,7 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 **发回响应报文的步骤和之前过程类似** - + ### 专用术语 @@ -654,13 +654,13 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 **实体** - + **协议** - + 1、协议：控制两个对等实体进行逻辑通信的规则的集合 @@ -676,13 +676,13 @@ Q：另外对于总线型的网络，还会出现下面这种典型的问题 **服务** - + - + - + diff --git a/docs/ElasticSearch/ElasticSearch-入门.md b/docs/ElasticSearch/ElasticSearch-入门.md index dd008f6..1103efc 100644 --- a/docs/ElasticSearch/ElasticSearch-入门.md +++ b/docs/ElasticSearch/ElasticSearch-入门.md @@ -9,7 +9,7 @@ categories: - 用法 keywords: ElasticSearch,全文检索 description: ElasticSearch-入门篇，适合做入门，或者知识回顾。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/ElasticSearch/logo.jpg' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/ElasticSearch/logo.jpg' abbrlink: 7f60dde9 date: 2020-02-03 13:11:45 --- @@ -46,7 +46,7 @@ date: 2020-02-03 13:11:45 下图是ElasticSearch的索引结构，下边黑色部分是物理结构，上边黄色部分是逻辑结构，逻辑结构也是为了更好的 去描述ElasticSearch的工作原理及去使用物理结构中的索引文件。 - + 逻辑结构部分是一个倒排索引表： @@ -58,11 +58,11 @@ date: 2020-02-03 13:11:45 如下： - + 现在，如果我们想搜到`quick brown`我们只需要查找包含每个词条的文档： - + 两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单 相似性算法 ， 那么，我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文档更佳 @@ -236,7 +236,7 @@ http://localhost:9200/xc_course/doc/4028e58161bcf7f40161bcf8b77c0000 使用postman测试： - + diff --git a/docs/ElasticSearch/ElasticSearch-进阶.md b/docs/ElasticSearch/ElasticSearch-进阶.md index d3e1fde..e1aa3b7 100644 --- a/docs/ElasticSearch/ElasticSearch-进阶.md +++ b/docs/ElasticSearch/ElasticSearch-进阶.md @@ -9,7 +9,7 @@ categories: - 用法 keywords: ElasticSearch,全文检索 description: ElasticSearch-进阶篇，ElasticSearch的一些实战用法，集成SpringBoot。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/ElasticSearch/logo.jpg' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/ElasticSearch/logo.jpg' abbrlink: 50e81c79 date: 2020-02-08 18:06:23 --- diff --git a/docs/JVM/JVM系列-第10章-垃圾回收概述和相关算法.md b/docs/JVM/JVM系列-第10章-垃圾回收概述和相关算法.md index 60f241b..1a40eba 100644 --- a/docs/JVM/JVM系列-第10章-垃圾回收概述和相关算法.md +++ b/docs/JVM/JVM系列-第10章-垃圾回收概述和相关算法.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第10章-垃圾回收概述和相关算法。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: d54daa0f date: 2020-11-16 18:14:02 --- @@ -20,7 +20,7 @@ date: 2020-11-16 18:14:02 - + 1. Java 和 C++语言的区别，就在于垃圾收集技术和内存动态分配上，C++语言没有垃圾收集技术，需要程序员手动的收集。 @@ -102,7 +102,7 @@ date: 2020-11-16 18:14:02 **十几年前磁盘碎片整理的日子** - + @@ -174,7 +174,7 @@ date: 2020-11-16 18:14:02 ### 应该关心哪些区域的回收？ - + 1. 垃圾收集器可以对年轻代回收，也可以对老年代回收，甚至是全栈和方法区的回收， 1. 其中，**Java堆是垃圾收集器的工作重点** @@ -216,7 +216,7 @@ date: 2020-11-16 18:14:02 ### 循环引用 - + 当p的指针断开的时候，内部的引用形成一个循环，计数器都还算1，无法被回收，这就是循环引用，从而造成内存泄漏 @@ -255,7 +255,7 @@ public class RefCountGC { - + * 如果不小心直接把`obj1.reference`和`obj2.reference`置为null。则在Java堆中的两块内存依然保持着互相引用，无法被回收 @@ -353,7 +353,7 @@ Process finished with exit code 0 3. 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。 4. 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。 - + @@ -371,7 +371,7 @@ Process finished with exit code 0 - 基本数据类型对应的Class对象，一些常驻的异常对象（如：NullPointerException、OutofMemoryError），系统类加载器。 7. 反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。 - + @@ -453,7 +453,7 @@ Object 类中 finalize() 源码 **通过 JVisual VM 查看 Finalizer 线程** - + @@ -579,7 +579,7 @@ MAT与JProfiler的GC Roots溯源 **方式一：命令行使用 jmap** - + @@ -631,23 +631,23 @@ public class GCRootsTest { 1、先执行第一步，然后停下来，去生成此步骤dump文件 - + 2、 点击【堆 Dump】 - + 3、右键 --\> 另存为即可 - + 4、输入命令，继续执行程序 - + 5、我们接着捕获第二张堆内存快照 - + @@ -657,19 +657,19 @@ public class GCRootsTest { > 点击Open Heap Dump也行 - + 2、选择Java Basics --> GC Roots - + 3、第一次捕捉堆内存快照时，GC Roots 中包含我们定义的两个局部变量，类型分别为 ArrayList 和 Date，Total:21 - + 4、打开第二个dump文件，第二次捕获内存快照时，由于两个局部变量引用的对象被释放，所以这两个局部变量不再作为 GC Roots ，从 Total Entries = 19 也可以看出（少了两个 GC Roots） - + @@ -716,13 +716,13 @@ public class GCRootsTest { 1、 - + 2、 - + - + 可以发现颜色变绿了，可以动态的看变化 @@ -730,11 +730,11 @@ public class GCRootsTest { 3、右击对象，选择 Show Selection In Heap Walker，单独的查看某个对象 - + - + @@ -742,13 +742,13 @@ public class GCRootsTest { 点击Show Paths To GC Roots，在弹出界面中选择默认设置即可 - + - + - + ### JProfiler 分析 OOM @@ -798,11 +798,11 @@ count = 6 1、看这个超大对象 - + 2、揪出 main() 线程中出问题的代码 - + @@ -837,7 +837,7 @@ count = 6 * 注意：标记的是被引用的对象，也就是可达对象，并非标记的是即将被清除的垃圾对象 2. 清除：Collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收 - + @@ -876,7 +876,7 @@ count = 6 将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收 - + 新生代里面就用到了复制算法，Eden区和S0区存活对象整体复制到S1区 @@ -906,7 +906,7 @@ count = 6 2. 老年代大量的对象存活，那么复制的对象将会有很多，效率会很低 3. 在新生代，对常规应用的垃圾回收，一次通常可以回收70% - 99% 的内存空间。回收性价比很高。所以现在的商业虚拟机都是用这种收集算法回收新生代。 - + @@ -935,7 +935,7 @@ count = 6 2. 第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。之后，清理边界外所有的空间。 - + @@ -1066,7 +1066,7 @@ A：无，没有最好的算法，只有最合适的算法 1. 一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。 3. 分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间。 - + diff --git a/docs/JVM/JVM系列-第11章-垃圾回收相关概念.md b/docs/JVM/JVM系列-第11章-垃圾回收相关概念.md index 64c5013..187f017 100644 --- a/docs/JVM/JVM系列-第11章-垃圾回收相关概念.md +++ b/docs/JVM/JVM系列-第11章-垃圾回收相关概念.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第11章-垃圾回收相关概念。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: 4d401a8b date: 2020-11-17 12:33:24 --- @@ -117,7 +117,7 @@ JVM参数： 2、我也查过了大对象阈值的默认值 - + 我不太懂这个默认值为啥是0，我猜测可能是代表什么比例，目前也没有搜到相关的东西。这个不太重要，暂时就没有太深究，希望读者有知道的可以告知我一声。 @@ -185,11 +185,11 @@ Heap 1、来看看字节码：实例方法局部变量表第一个变量肯定是 this - + 2、你有没有看到，局部变量表的大小是 2。但是局部变量表里只有一个索引为0的啊？那索引为1的是哪个局部变量呢？实际上索引为1的位置是buffer在占用着，执行 System.gc() 时，栈中还有 buffer 变量指向堆中的字节数组，所以没有进行GC - + 3、那么这种代码块的情况，什么时候会被GC呢？我们来看第四个方法 @@ -217,11 +217,11 @@ A：局部变量表长度为 2 ，这说明了出了代码块时，buffer 就出 > 这点看不懂的可以看我前面的文章：虚拟机栈 --> Slot的重复利用 - + - + @@ -302,7 +302,7 @@ Heap 右边的图：后期有一些对象不用了，按道理应该断开引用，但是存在一些链没有断开（图示中的Forgotten Reference Memory Leak），从而导致没有办法被回收。 - + @@ -446,7 +446,7 @@ Process finished with exit code -1 2. 并发不是真正意义上的“同时进行”，只是CPU把一个时间段划分成几个时间片段（时间区间），然后在这几个时间区间之间来回切换。由于CPU处理的速度非常快，只要时间间隔处理得当，即可让用户感觉是多个应用程序同时在进行 - + @@ -461,7 +461,7 @@ Process finished with exit code -1 3. 适合科学计算，后台处理等弱交互场景 - + > **并发与并行的对比** @@ -482,7 +482,7 @@ Process finished with exit code -1 * 相较于并行的概念，单线程执行。 * 如果内存不够，则程序暂停，启动JVM垃圾回收器进行垃圾回收（单线程） - + @@ -492,7 +492,7 @@ Process finished with exit code -1 - 比如用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上； 2. 典型垃圾回收器：CMS、G1 - + @@ -551,7 +551,7 @@ Process finished with exit code -1 1、一般的垃圾回收算法至少会划分出两个年代，年轻代和老年代。但是单纯的分代理论在垃圾回收的时候存在一个巨大的缺陷：为了找到年轻代中的存活对象，却不得不遍历整个老年代，反过来也是一样的。 - + 2、如果我们从年轻代开始遍历，那么可以断定N, S, P, Q都是存活对象。但是，V却不会被认为是存活对象，其占据的内存会被回收了。这就是一个惊天的大漏洞！因为U本身是老年代对象，而且有外部引用指向它，也就是说U是存活对象，而U指向了V，也就是说V也应该是存活对象才是！而这都是因为我们只遍历年轻代对象！ @@ -599,7 +599,7 @@ Process finished with exit code -1 4. 这4种引用强度依次逐渐减弱。除强引用外，其他3种引用均可以在java.lang.ref包中找到它们的身影。如下图，显示了这3种引用类型对应的类，开发人员可以在应用程序中直接使用它们。 - + @@ -661,7 +661,7 @@ Hello,尚硅谷 `StringBuffer str = new StringBuffer("hello,尚硅谷");` - + diff --git a/docs/JVM/JVM系列-第12章-垃圾回收器.md b/docs/JVM/JVM系列-第12章-垃圾回收器.md index bedb653..f47b180 100644 --- a/docs/JVM/JVM系列-第12章-垃圾回收器.md +++ b/docs/JVM/JVM系列-第12章-垃圾回收器.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第12章-垃圾回收器。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: 7706d61d date: 2020-11-19 18:33:24 --- @@ -44,7 +44,7 @@ GC 分类与性能指标 **按线程数分（垃圾回收线程数），可以分为串行垃圾回收器和并行垃圾回收器。** - + 1. 串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直至垃圾收集工作结束。 1. 在诸如单CPU处理器或者较小的应用内存等硬件平台不是特别优越的场合，串行回收器的性能表现可以超过并行回收器和并发回收器。所以，串行回收默认被应用在客户端的Client模式下的JVM中 @@ -60,7 +60,7 @@ GC 分类与性能指标 1. 并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间。 2. 独占式垃圾回收器（Stop the World）一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束。 - + @@ -105,7 +105,7 @@ GC 分类与性能指标 2. 这种情况下，应用程序能容忍较高的暂停时间，因此，高吞吐量的应用程序有更长的时间基准，快速响应是不必考虑的 3. 吞吐量优先，意味着在单位时间内，STW的时间最短：0.2+0.2=0.4 - + @@ -115,7 +115,7 @@ GC 分类与性能指标 - 例如，GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的 2. 暂停时间优先，意味着尽可能让单次STW的时间最短：0.1+0.1 + 0.1+ 0.1+ 0.1=0.5，但是总的GC时间可能会长 - + @@ -169,17 +169,17 @@ GC 分类与性能指标 2. 并行回收器：ParNew、Parallel Scavenge、Parallel old 3. 并发回收器：CMS、G1 - + **官方文档** - + **7款经典回收器与垃圾分代之间的关系** - + 1. 新生代收集器：Serial、ParNew、Parallel Scavenge； @@ -192,7 +192,7 @@ GC 分类与性能指标 ### 垃圾收集器的组合关系 - + @@ -251,11 +251,11 @@ jinfo -flag UseParallelOldGC 进程id JDK 8 中默认使用 ParallelGC 和 ParallelOldGC 的组合 - + #### JDK9 - + @@ -281,7 +281,7 @@ Serial 回收器：串行回收 这个收集器是一个单线程的收集器，“单线程”的意义：它只会使用一个CPU（串行）或一条收集线程去完成垃圾收集工作。更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束（Stop The World） - + @@ -313,7 +313,7 @@ ParNew 回收器：并行回收 2. ParNew 收集器除了采用**并行回收**的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。ParNew收集器在年轻代中同样也是采用复制算法、"Stop-the-World"机制。 3. ParNew 是很多JVM运行在Server模式下新生代的默认垃圾收集器。 - + 1. 对于新生代，回收次数频繁，使用并行方式高效。 2. 对于老年代，回收次数少，使用串行方式节省资源。（CPU并行需要切换线程，串行可以省去切换线程的资源） @@ -361,7 +361,7 @@ Parallel 回收器：吞吐量优先 5. Parallel Old收集器采用了标记-压缩算法，但同样也是基于并行回收和"Stop-the-World"机制。 - + 1. 在程序吞吐量优先的应用场景中，Parallel收集器和Parallel Old收集器的组合，在server模式下的内存回收性能很不错。 2. **在Java8中，默认是此垃圾收集器。** @@ -418,7 +418,7 @@ CMS 回收器：低延迟 ### CMS 工作原理（过程） - + CMS整个过程比之前的收集器要复杂，整个过程分为4个主要阶段，即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。(涉及STW的阶段主要是：初始标记 和 重新标记) @@ -438,7 +438,7 @@ CMS整个过程比之前的收集器要复杂，整个过程分为4个主要阶 3. 另外，由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，**而是当堆内存使用率达到某一阈值时，便开始进行回收**，以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次**“Concurrent Mode Failure”** 失败，这时虚拟机将启动后备预案：临时启用Serial old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。 4. CMS收集器的垃圾收集算法采用的是**标记清除算法**，这意味着每次执行完内存回收后，由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，**不可避免地将会产生一些内存碎片**。那么CMS在为新对象分配内存空间时，将无法使用指针碰撞（Bump the Pointer）技术，而只能够选择空闲列表（Free List）执行内存分配。 - + @@ -558,11 +558,11 @@ G1 回收器：区域化分代式 G1的分代，已经不是下面这样的了 - + G1的分区是这样的一个区域 - + **空间整合** @@ -655,7 +655,7 @@ G1中提供了三种垃圾回收模式：YoungGC、Mixed GC和Full GC，在不 > > 如图所示，可以将区域分配到Eden，幸存者和旧时代区域。 此外，还有第四种类型的物体被称为巨大区域。 这些区域旨在容纳标准区域大小的50％或更大的对象。 它们存储为一组连续区域。 最后，最后一种区域类型是堆的未使用区域。 - + @@ -667,7 +667,7 @@ G1中提供了三种垃圾回收模式：YoungGC、Mixed GC和Full GC，在不 **Regio的细节** - + 1. 每个Region都是通过指针碰撞来分配空间 2. G1为每一个Region设 计了两个名为TAMS（Top at Mark Start）的指针，把Region中的一部分空间划分出来用于并发回收过程中的新对象分配，并发回收时新分配的对象地址都必须要在这两个指针位置以上。 @@ -686,7 +686,7 @@ G1 GC的垃圾回收过程主要包括如下三个环节： * 混合回收（Mixed GC） * （如果需要，单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收。） - + 顺时针，Young GC --> Young GC+Concurrent Marking --> Mixed GC顺序，进行垃圾回收 @@ -731,7 +731,7 @@ G1 GC的垃圾回收过程主要包括如下三个环节： - + 1. 在回收 Region 时，为了不进行全堆的扫描，引入了 Remembered Set 2. Remembered Set 记录了当前 Region 中的对象被哪个对象引用了 @@ -748,7 +748,7 @@ G1 GC的垃圾回收过程主要包括如下三个环节： 2. 年轻代回收只回收Eden区和Survivor区 3. YGC时，首先G1停止应用程序的执行（Stop-The-World），G1创建回收集（Collection Set），回收集是指需要被回收的内存分段的集合，年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段。 - + 图的大致意思就是： @@ -804,7 +804,7 @@ G1 GC的垃圾回收过程主要包括如下三个环节： 当越来越多的对象晋升到老年代Old Region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即Mixed GC，该算法并不是一个Old GC，除了回收整个Young Region，还会回收一部分的Old Region。这里需要注意：是一部分老年代，而不是全部老年代。可以选择哪些Old Region进行收集，从而可以对垃圾回收的耗时时间进行控制。也要注意的是Mixed GC并不是Full GC。 - + @@ -854,11 +854,11 @@ G1 GC的垃圾回收过程主要包括如下三个环节： 截止JDK1.8，一共有7款不同的垃圾收集器。每一款的垃圾收集器都有不同的特点，在具体使用的时候，需要根据具体的情况选用不同的垃圾收集器。 - + - + @@ -922,11 +922,11 @@ GC 日志分析 2、这个只会显示总的GC堆的变化，如下： - + 3、参数解析 - + @@ -938,11 +938,11 @@ GC 日志分析 2、输入信息如下 - + 3、参数解析 - + @@ -954,7 +954,7 @@ GC 日志分析 2、输出信息如下 - + 3、说明：日志带上了日期和时间 @@ -989,13 +989,13 @@ GC 日志分析 #### Young GC - + #### Full GC - + @@ -1029,11 +1029,11 @@ public class GCLogTest1 { 1、首先我们会将3个2M的数组存放到Eden区，然后后面4M的数组来了后，将无法存储，因为Eden区只剩下2M的剩余空间了，那么将会进行一次Young GC操作，将原来Eden区的内容，存放到Survivor区，但是Survivor区也存放不下，那么就会直接晋级存入Old 区 - + 2、然后我们将4M对象存入到Eden区中 - + 老年代图画的有问题，free应该是4M @@ -1056,7 +1056,7 @@ Process finished with exit code 0 ``` - + 与 JDK7 不同的是，JDK8 直接判定 4M 的数组为大对象，直接怼到老年区去了 @@ -1082,15 +1082,15 @@ GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat等 在线分析网址：gceasy.io - + - + - + @@ -1126,7 +1126,7 @@ GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat等 1. 停顿时间比其他几款收集器确实有了质的飞跃，但也未实现最大停顿时间控制在十毫秒以内的目标。 2. 而吞吐量方面出现了明显的下降，总运行时间是所有测试收集器里最长的。 - + @@ -1156,7 +1156,7 @@ GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat等 **吞吐量** - + max-JOPS：以低延迟为首要前提下的数据 @@ -1166,13 +1166,13 @@ critical-JOPS：不考虑低延迟下的数据 **低延迟** - + 在ZGC的强项停顿时间测试上，它毫不留情的将Parallel、G1拉开了两个数量级的差距。无论平均停顿、95%停顿、998停顿、99. 98停顿，还是最大停顿时间，ZGC都能毫不费劲控制在10毫秒以内。 虽然ZGC还在试验状态，没有完成所有特性，但此时性能已经相当亮眼，用“令人震惊、革命性”来形容，不为过。未来将在服务端、大内存、低延迟应用的首选垃圾收集器。 - + @@ -1192,4 +1192,4 @@ critical-JOPS：不考虑低延迟下的数据 AliGC是阿里巴巴JVM团队基于G1算法，面向大堆（LargeHeap）应用场景。指定场景下的对比： - \ No newline at end of file + \ No newline at end of file diff --git a/docs/JVM/JVM系列-第1章-JVM与Java体系结构.md b/docs/JVM/JVM系列-第1章-JVM与Java体系结构.md index b84c840..e160458 100644 --- a/docs/JVM/JVM系列-第1章-JVM与Java体系结构.md +++ b/docs/JVM/JVM系列-第1章-JVM与Java体系结构.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第1章-JVM与Java体系结构。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: 8c954c6 date: 2020-11-02 11:51:56 --- @@ -38,7 +38,7 @@ date: 2020-11-02 11:51:56 3. 新项目上线，对各种JVM参数设置一脸茫然，直接默认吧然后就JJ了。 4. 每次面试之前都要重新背一遍JVM的一些原理概念性的东西，然而面试官却经常问你在实际项目中如何调优VM参数，如何解决GC、OOM等问题，一脸懵逼。 - + 大部分Java开发人员，除了会在项目中使用到与Java平台相关的各种高精尖技术，对于Java技术的核心Java虚拟机了解甚少。 @@ -50,7 +50,7 @@ date: 2020-11-02 11:51:56 1. 一些有一定工作经验的开发人员，打心眼儿里觉得SSM、微服务等上层技术才是重点，基础技术并不重要，这其实是一种本末倒置的“病态”。 2. 如果我们把核心类库的API比做数学公式的话，那么Java虚拟机的知识就好比公式的推导过程。 - + - 计算机系统体系对我们来说越来越远，在不了解底层实现方式的前提下，通过高级语言很容易编写程序代码。但事实上计算机并不认识高级语言。 @@ -87,7 +87,7 @@ Java VS C++ 1. 垃圾收集机制为我们打理了很多繁琐的工作，大大提高了开发的效率，但是，垃圾收集也不是万能的，懂得JVM内部的内存结构、工作机制，是设计高扩展性应用和诊断运行时问题的基础，也是Java工程师进阶的必备能力。 2. C++语言需要程序员自己来分配内存和回收内存，对于高手来说可能更加舒服，但是对于普通开发者，如果技术实力不够，很容易造成内存泄漏。而Java全部交给JVM进行内存分配和回收，这也是一种趋势，减少程序员的工作量。 - + ## 什么人需要学JVM？ @@ -103,26 +103,26 @@ Java VS C++ **英文文档规范**：https://docs.oracle.com/javase/specs/index.html - + **中文书籍：** - + > 周志明老师的这本书**非常推荐看**，不过只推荐看第三版，第三版较第二版更新了很多，个人觉得没必要再看第二版。 - + - + TIOBE排行榜 ----------- **TIOBE 排行榜**：https://www.tiobe.com/tiobe-index/ - + - 世界上没有最好的编程语言，只有最适用于具体应用场景的编程语言。 - 目前网上一直流传Java被python，go撼动Java第一的地位。学习者不需要太担心，Java强大的生态圈，也不是说是朝夕之间可以被撼动的。 @@ -148,14 +148,14 @@ Java-跨平台的语言 - + JVM-跨语言的平台 ------ - + @@ -187,7 +187,7 @@ JVM-跨语言的平台 2. 自己动手写一个Java虚拟机，难吗？ 3. 天下事有难易乎？为之，则难者亦易矣；不为，则易者亦难矣 - + Java发展重大事件 ------------ @@ -215,7 +215,7 @@ Java发展重大事件 ## Open JDK和Oracle JDK - + - 在JDK11之前，Oracle JDK中还会存在一些Open JDK中没有的，闭源的功能。但在JDK11中，我们可以认为Open JDK和Oracle JDK代码实质上已经达到完全一致的程度了。 - 主要的区别就是两者更新周期不一样 @@ -258,11 +258,11 @@ JVM的位置 JVM是运行在操作系统之上的，它与硬件没有直接的交互 - + - + @@ -275,7 +275,7 @@ JVM的整体结构 - + @@ -284,7 +284,7 @@ Java代码执行流程 凡是能生成被Java虚拟机所能解释、运行的字节码文件，那么理论上我们就可以自己设计一套语言了 - + diff --git a/docs/JVM/JVM系列-第2章-类加载子系统.md b/docs/JVM/JVM系列-第2章-类加载子系统.md index a409621..9c75cd0 100644 --- a/docs/JVM/JVM系列-第2章-类加载子系统.md +++ b/docs/JVM/JVM系列-第2章-类加载子系统.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第2章-类加载子系统。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: 2e0079af date: 2020-11-02 21:31:58 --- @@ -25,19 +25,19 @@ date: 2020-11-02 21:31:58 ### 简图 - + ### 详细图 英文版 - + 中文版 - + 注意：方法区只有HotSpot虚拟机有，J9，JRockit都没有 @@ -59,7 +59,7 @@ date: 2020-11-02 21:31:58 3. **加载的类信息存放于一块称为方法区的内存空间**。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射） - + @@ -71,7 +71,7 @@ date: 2020-11-02 21:31:58 - + 类加载过程 ------- @@ -96,11 +96,11 @@ public class HelloLoader { * 加载成功，则进行链接、初始化等操作。完成后调用 HelloLoader 类中的静态方法 main * 加载失败则抛出异常 - + 完整的流程图如下所示： - + @@ -142,7 +142,7 @@ public class HelloLoader { 使用 BinaryViewer软件查看字节码文件，其开头均为 CAFE BABE ，如果出现不合法的字节码文件，那么将会验证不通过。 - + #### 准备(Prepare) @@ -185,7 +185,7 @@ public class HelloApp { * 反编译 class 文件后可以查看符号引用，下面带# 的就是符号引用 - + ### 初始化阶段 @@ -225,7 +225,7 @@ public class HelloApp { 查看下面这个代码的字节码，可以发现有一个`()`方法。 - + ```java public class ClassInitTest { @@ -277,15 +277,15 @@ public class ClassInitTest { **举例2：无 static 变量** - + 加上之后就有了 - + #### 4说明 - + 在构造器中： @@ -296,7 +296,7 @@ public class ClassInitTest { 若该类具有父类，JVM会保证子类的`()`执行前，父类的`()`已经执行完毕 - + 如上代码，加载流程如下： @@ -374,17 +374,17 @@ class DeadThread{ - + **ExtClassLoader** - + **AppClassLoader** - + @@ -579,15 +579,15 @@ public class CustomClassLoader extends ClassLoader { ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器） - + sun.misc.Launcher 它是一个java虚拟机的入口应用 - + #### 获取ClassLoader途径 - + @@ -640,7 +640,7 @@ Java虚拟机对class文件采用的是**按需加载**的方式，也就是说 3. 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。 4. 父类加载器一层一层往下分配任务，如果子类加载器能加载，则加载此类，如果将加载任务分配至系统类加载器也无法加载此类，则抛出异常 - + ### 双亲委派机制代码演示 @@ -707,7 +707,7 @@ public class String { } ``` - + 由于双亲委派机制一直找父类，所以最后找到了Bootstrap ClassLoader，Bootstrap ClassLoader找到的是 JDK 自带的 String 类，在那个String类中并没有 main() 方法，所以就报了上面的错误。 @@ -765,7 +765,7 @@ Process finished with exit code 1 - + diff --git a/docs/JVM/JVM系列-第3章-运行时数据区.md b/docs/JVM/JVM系列-第3章-运行时数据区.md index 6f2cab7..51d010d 100644 --- a/docs/JVM/JVM系列-第3章-运行时数据区.md +++ b/docs/JVM/JVM系列-第3章-运行时数据区.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第3章-运行时数据区。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: a7ad3cab date: 2020-11-09 15:38:42 --- @@ -27,15 +27,15 @@ date: 2020-11-09 15:38:42 本节主要讲的是运行时数据区，也就是下图这部分，它是在类加载完成后的阶段 - + 当我们通过前面的：类的加载 --> 验证 --> 准备 --> 解析 --\> 初始化，这几个阶段完成后，就会用到执行引擎对我们的类进行使用，同时执行引擎将会使用到我们运行时数据区 - + 类比一下也就是大厨做饭，我们把大厨后面的东西（切好的菜，刀，调料），比作是运行时数据区。而厨师可以类比于执行引擎，将通过准备的东西进行制作成精美的菜品。 - + @@ -50,7 +50,7 @@ date: 2020-11-09 15:38:42 > 下图来自阿里巴巴手册JDK8 - + @@ -62,7 +62,7 @@ date: 2020-11-09 15:38:42 - 线程独有：独立包括程序计数器、栈、本地方法栈 - 线程间共享：堆、堆外内存（永久代或元空间、代码缓存） - + @@ -70,7 +70,7 @@ date: 2020-11-09 15:38:42 **每个JVM只有一个Runtime实例**。即为运行时环境，相当于内存结构的中间的那个框框：运行时环境。 - + @@ -114,7 +114,7 @@ PC寄存器介绍 > 官方文档网址：https://docs.oracle.com/javase/specs/jvms/se8/html/index.html - + 1. JVM中的程序计数寄存器（Program Counter Register）中，Register的命名源于CPU的寄存器，**寄存器存储指令相关的现场信息**。CPU只有把数据装载到寄存器才能够运行。 2. 这里，并非是广义上所指的物理寄存器，或许将其翻译为PC计数器（或指令计数器）会更加贴切（也称为程序钩子），并且也不容易引起一些不必要的误会。**JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟**。 @@ -132,7 +132,7 @@ PC寄存器介绍 PC寄存器用来存储指向下一条指令的地址，也即将要执行的指令代码。由执行引擎读取下一条指令，并执行该指令。 - + @@ -268,7 +268,7 @@ SourceFile: "PCRegisterTest.java" * 左边的数字代表**指令地址（指令偏移）**，即 PC 寄存器中可能存储的值，然后执行引擎读取 PC 寄存器中的值，并执行该指令 - + @@ -282,7 +282,7 @@ SourceFile: "PCRegisterTest.java" 2. JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令 - + @@ -306,7 +306,7 @@ CPU 时间片 3. 但在微观上：由于只有一个CPU，一次只能处理程序要求的一部分，如何处理公平，一种方法就是引入时间片，**每个程序轮流执行**。 - + @@ -314,7 +314,7 @@ CPU 时间片 ## 本地方法 - + @@ -393,7 +393,7 @@ Java使用起来非常方便，然而有些层次的任务用Java实现起来不 4. 本地方法一般是使用C语言或C++语言实现的。 5. 它的具体做法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。 - + diff --git a/docs/JVM/JVM系列-第4章-虚拟机栈.md b/docs/JVM/JVM系列-第4章-虚拟机栈.md index 619bfc6..3a97fa7 100644 --- a/docs/JVM/JVM系列-第4章-虚拟机栈.md +++ b/docs/JVM/JVM系列-第4章-虚拟机栈.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第4章-虚拟机栈。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: 5b1b6560 date: 2020-11-10 10:38:42 --- @@ -31,7 +31,7 @@ date: 2020-11-10 10:38:42 1. 首先栈是运行时的单位，而堆是存储的单位。 2. 即：栈解决程序的运行问题，即程序如何执行，或者说如何处理数据。堆解决的是数据存储的问题，即数据怎么放，放哪里 - + @@ -66,7 +66,7 @@ date: 2020-11-10 10:38:42 - + - 虚拟机栈的生命周期 - 生命周期和线程一致，也就是线程结束了，该虚拟机栈也销毁了 @@ -90,7 +90,7 @@ date: 2020-11-10 10:38:42 - 对于栈来说不存在垃圾回收问题 - 栈不需要GC，但是可能存在OOM - + ### 虚拟机栈的异常 @@ -164,7 +164,7 @@ Exception in thread "main" java.lang.StackOverflowError **设置栈参数之后** - + 部分输出结果 @@ -202,7 +202,7 @@ Exception in thread "main" java.lang.StackOverflowError 4. 如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前帧。 - + 1. **不同线程中所包含的栈帧是不允许存在相互引用的**，即不可能在一个栈帧之中引用另外一个线程的栈帧。 2. 如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧。 @@ -230,11 +230,11 @@ Exception in thread "main" java.lang.StackOverflowError - 一些附加信息 - + 并行每个线程下的栈都是私有的，因此每个线程都有自己各自的栈，并且每个栈里面都有很多栈帧，栈帧的大小主要由局部变量表 和 操作数栈决定的 - + 局部变量表 ------- @@ -312,7 +312,7 @@ public class LocalVariablesTest { } ``` - + 看完字节码后，可得结论：所以局部变量表所需的容量大小是在编译期确定下来的。 @@ -324,29 +324,29 @@ public class LocalVariablesTest { 1、0-15 也就是有16行字节码 - + 2、方法异常信息表 - + 3、Misc - + 4、行号表 Java代码的行号和字节码指令行号的对应关系 - + 5、注意：生效行数和剩余有效行数都是针对于字节码文件的行数 - + 1、图中圈的东西表示该局部变量的作用域 @@ -370,7 +370,7 @@ Java代码的行号和字节码指令行号的对应关系 6. 如果需要访问局部变量表中一个64bit的局部变量值时，只需要使用前一个索引即可。（比如：访问long或double类型变量） 7. 如果当前帧是由构造方法或者实例方法创建的，那么**该对象引用this将会存放在index为0的slot处**，其余的参数按照参数表顺序继续排列。（this也相当于一个变量） - + ### Slot代码示例 @@ -388,7 +388,7 @@ Java代码的行号和字节码指令行号的对应关系 局部变量表：this 存放在 index = 0 的位置 - + @@ -408,7 +408,7 @@ Java代码的行号和字节码指令行号的对应关系 weight 为 double 类型，index 直接从 3 蹦到了 5 - + @@ -451,7 +451,7 @@ this 不存在与 static 方法的局部变量表中，所以无法调用 局部变量 c 重用了局部变量 b 的 slot 位置 - + @@ -499,13 +499,13 @@ this 不存在与 static 方法的局部变量表中，所以无法调用 - 比如：执行复制、交换、求和等操作 - + - + @@ -536,7 +536,7 @@ this 不存在与 static 方法的局部变量表中，所以无法调用 - + 局部变量表就相当于食材 @@ -571,23 +571,23 @@ this 不存在与 static 方法的局部变量表中，所以无法调用 10 return ``` - + ### 一步一步看流程 1、首先执行第一条语句，PC寄存器指向的是0，也就是指令地址为0，然后使用bipush让操作数15入操作数栈。 - + 2、执行完后，PC寄存器往下移，指向下一行代码，下一行代码就是将操作数栈的元素存储到局部变量表1的位置（istore_1），我们可以看到局部变量表的已经增加了一个元素。并且操作数栈为空了 * 解释为什么局部变量表索引从 1 开始，因为该方法为实例方法，局部变量表索引为 0 的位置存放的是 this - + 3、然后PC下移，指向的是下一行。让操作数8也入栈，同时执行store操作，存入局部变量表中 - + @@ -595,11 +595,11 @@ this 不存在与 static 方法的局部变量表中，所以无法调用 iload_1：取出局部变量表中索引为1的数据入操作数栈 - + 5、然后将操作数栈中的两个元素执行相加操作，并存储在局部变量表3的位置 - + @@ -607,7 +607,7 @@ iload_1：取出局部变量表中索引为1的数据入操作数栈 **关于类型转换的说明** - + @@ -616,7 +616,7 @@ iload_1：取出局部变量表中索引为1的数据入操作数栈 - + - m改成800之后，byte存储不了，就成了short型，sipush 800 @@ -645,11 +645,11 @@ iload_1：取出局部变量表中索引为1的数据入操作数栈 getSum() 方法字节码指令：最后带着个 ireturn - + testGetSum() 方法字节码指令：一上来就加载 getSum() 方法的返回值() - + @@ -841,7 +841,7 @@ SourceFile: "DynamicLinkingTest.java" - + @@ -1136,7 +1136,7 @@ interface MethodInterface { Son 类中 show() 方法的字节码指令如下 - + @@ -1176,7 +1176,7 @@ public class Lambda { } ``` - + @@ -1233,7 +1233,7 @@ Java：String info = "mogu blog"; (Java是静态类型语言的，会先 如图所示：如果类中重写了方法，那么调用的时候，就会直接在该类的虚方法表中查找 - + 1、比如说son在调用toString的时候，Son没有重写过，Son的父类Father也没有重写过，那就直接调用Object类的toString。那么就直接在虚方法表里指明toString直接指向Object类。 @@ -1243,24 +1243,24 @@ Java：String info = "mogu blog"; (Java是静态类型语言的，会先 **例子2** - + - + - + - + 方法返回地址 -------- - + > 在一些帖子里，方法返回地址、动态链接、一些附加信息 也叫做帧数据区 @@ -1309,7 +1309,7 @@ Java：String info = "mogu blog"; (Java是静态类型语言的，会先 2. 方法执行过程中，抛出异常时的异常处理，存储在一个异常处理表，方便在发生异常的时候找到处理异常的代码 - + @@ -1321,7 +1321,7 @@ Java：String info = "mogu blog"; (Java是静态类型语言的，会先 * target ：出现异常跳转至地址为 11 的指令执行 * type ：捕获异常的类型 - + diff --git a/docs/JVM/JVM系列-第5章-堆.md b/docs/JVM/JVM系列-第5章-堆.md index 1ba46e8..15dc89e 100644 --- a/docs/JVM/JVM系列-第5章-堆.md +++ b/docs/JVM/JVM系列-第5章-堆.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第5章-堆。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: 50ac3a1c date: 2020-11-11 20:38:42 --- @@ -27,7 +27,7 @@ date: 2020-11-11 20:38:42 1. 堆针对一个JVM进程来说是唯一的。也就是**一个进程只有一个JVM实例**，一个JVM实例中就有一个运行时数据区，一个运行时数据区只有一个堆和一个方法区。 2. 但是**进程包含多个线程，他们是共享同一堆空间的**。 - + @@ -68,7 +68,7 @@ public class SimpleHeap { } ``` - + @@ -88,13 +88,13 @@ public class SimpleHeap { 约定：新生区 <–> 新生代 <–> 年轻代 、 养老区 <–> 老年区 <–> 老年代、 永久区 <–\> 永久代 - + 2. 堆空间内部结构，JDK1.8之前从永久代 替换成 元空间 - + @@ -122,17 +122,17 @@ public class HeapDemo { 1、双击jdk目录下的这个文件 - + 2、工具 -> 插件 -> 安装Visual GC插件 - + 3、运行上面的代码 - + @@ -215,7 +215,7 @@ public class HeapSpaceInitial { 设置下参数再看 - + ```java public class HeapSpaceInitial { @@ -250,7 +250,7 @@ public class HeapSpaceInitial { **方式一： jps / jstat -gc 进程id** - + > jps：查看java进程 > @@ -285,7 +285,7 @@ OU: 老年代使用的量 **方式二：-XX:+PrintGCDetails** - + @@ -333,11 +333,11 @@ Process finished with exit code 1 2、堆内存变化图 - + 3、原因：大对象导致堆内存溢出 - + @@ -357,9 +357,9 @@ Process finished with exit code 1 3、其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间（有时也叫做from区、to区） - + - + - 配置新生代与老年代在堆结构的占比 @@ -383,7 +383,7 @@ Process finished with exit code 1 - + @@ -439,7 +439,7 @@ public class EdenSurvivorTest { 1、我们创建的对象，一般都是存放在Eden区的，**当我们Eden区满了后，就会触发GC操作**，一般被称为 YGC / Minor GC操作 - + 2、当我们进行一次垃圾收集后，红色的对象将会被回收，而绿色的独享还被占用着，存放在S0(Survivor From)区。同时我们给每个对象设置了一个年龄计数器，经过一次回收后还存在的对象，将其年龄加 1。 @@ -453,11 +453,11 @@ public class EdenSurvivorTest { > > 3、也就是说s0区和s1区在互相转换。 - + 4、我们继续不断的进行对象生成和垃圾回收，当Survivor中的对象的年龄达到15的时候，将会触发一次 Promotion 晋升的操作，也就是将年轻代中的对象晋升到老年代中 - + 关于垃圾回收：频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间收集。 @@ -475,7 +475,7 @@ public class EdenSurvivorTest { * 那万一老年代都放不下，则先触发FullGC ，再看看能不能放下，放得下最好，但如果还是放不下，那只能报 OOM 3. 如果 Eden 区满了，将对象往幸存区拷贝时，发现幸存区放不下啦，那只能便宜了某些新对象，让他们直接晋升至老年区 - + ### 常用调优工具 @@ -528,7 +528,7 @@ GC分类 3. Minor GC会引发STW（Stop The World），暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行 - + @@ -649,7 +649,7 @@ Heap * 新生代：有Eden、两块大小相同的survivor（又称为from/to或s0/s1）构成，to总为空。 * 老年代：存放新生代中经历多次GC仍然存活的对象。 - + @@ -661,7 +661,7 @@ Heap - + @@ -711,7 +711,7 @@ TLAB（Thread Local Allocation Buffer） 2. 多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为**快速分配策略**。 3. 据我所知所有OpenJDK衍生出来的JVM都提供了TLAB的设计。 - + 1、每个线程都有一个TLAB空间 @@ -741,7 +741,7 @@ TLAB（Thread Local Allocation Buffer） **TLAB 分配过程** - + diff --git a/docs/JVM/JVM系列-第6章-方法区.md b/docs/JVM/JVM系列-第6章-方法区.md index 6338502..32e6cbd 100644 --- a/docs/JVM/JVM系列-第6章-方法区.md +++ b/docs/JVM/JVM系列-第6章-方法区.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第6章-方法区。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: 136cd965 date: 2020-11-13 19:38:42 --- @@ -24,7 +24,7 @@ date: 2020-11-13 19:38:42 ThreadLocal：如何保证多个线程在并发环境下的安全性？典型场景就是数据库连接管理，以及会话管理。 - + **栈、堆、方法区的交互关系** @@ -35,7 +35,7 @@ ThreadLocal：如何保证多个线程在并发环境下的安全性？典型场 3. 真正的 person 对象存放在 Java 堆中 4. 在 person 对象中，有个指针指向方法区中的 person 类型数据，表明这个 person 对象是用方法区中的 Person 类 new 出来的 - + 方法区的理解 -------- @@ -47,7 +47,7 @@ ThreadLocal：如何保证多个线程在并发环境下的安全性？典型场 1. 《Java虚拟机规范》中明确说明：尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。但对于HotSpotJVM而言，方法区还有一个别名叫做Non-Heap（非堆），目的就是要和堆分开。 3. 所以，**方法区可以看作是一块独立于Java堆的内存空间**。 - + @@ -87,7 +87,7 @@ public class MethodAreaDemo { 简单的程序，加载了1600多个类 - + @@ -103,7 +103,7 @@ public class MethodAreaDemo { 5. 永久代、元空间二者并不只是名字变了，内部结构也调整了 6. 根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OOM异常 - + @@ -120,7 +120,7 @@ public class MethodAreaDemo { 2. -XX:MaxPermsize来设定永久代最大可分配空间。32位机器默认是64M，64位机器模式是82M 3. 当JVM加载的类信息容量超过了这个值，会报异常OutofMemoryError:PermGen space。 - + ### JDK8及以后(元空间) @@ -228,11 +228,11 @@ Exception in thread "main" java.lang.OutOfMemoryError: Metaspace #### 概念 - + 《深入理解Java虚拟机》书中对方法区（Method Area）存储内容描述如下：它用于存储已被虚拟机加载的**类型信息、常量、静态变量、即时编译器编译后的代码缓存**等。 - + @@ -714,7 +714,7 @@ public static int count; - + 1. 方法区，内部包含了运行时常量池 2. 字节码文件，内部包含了常量池。（之前的字节码文件中已经看到了很多Constant pool的东西，这个就是常量池） @@ -728,7 +728,7 @@ public static int count; 1. 一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述符信息外。还包含一项信息就是**常量池表**（**Constant Pool Table**），包括各种字面量和对类型、域和方法的符号引用。 2. 字面量： 10 ， “我是某某”这种数字和字符串都是字面量 - + **为什么需要常量池？** @@ -749,7 +749,7 @@ public static int count; 2. 比如说我们这个文件中有6个地方用到了"hello"这个字符串，如果不用常量池，就需要在6个地方全写一遍，造成臃肿。我们可以将"hello"等所需用到的结构信息记录在常量池中，并通过**引用的方式**，来加载、调用所需的结构 4. 这里的代码量其实很少了，如果代码多的话，引用的结构将会更多，这里就需要用到常量池了。 - + **常量池中有啥？** @@ -924,69 +924,69 @@ SourceFile: "MethodAreaDemo.java" 1、初始状态 - + 2、首先将操作数500压入操作数栈中 - + 3、然后操作数 500 从操作数栈中取出，存储到局部变量表中索引为 1 的位置 - + 4、 - + 5、 - + 6、 - + 7、 - + 8、 - + 9、 - + 10、 - + 11、图片写错了是#25和#26（获得System类） - + 12、 - + 13、 - + 15、执行加法运算后，将计算结果放在操作数栈顶 - + 16、就是真正的打印 - + 17、 - + @@ -1021,7 +1021,7 @@ SourceFile: "MethodAreaDemo.java" 方法区由永久代实现，使用 JVM 虚拟机内存（虚拟的内存） - + @@ -1029,7 +1029,7 @@ SourceFile: "MethodAreaDemo.java" 方法区由永久代实现，使用 JVM 虚拟机内存 - + @@ -1037,7 +1037,7 @@ SourceFile: "MethodAreaDemo.java" 方法区由元空间实现，使用物理机本地内存 - + @@ -1095,15 +1095,15 @@ public class StaticFieldTest { JDK6环境下 -image-20201113224231761 +image-20201113224231761 JDK7环境下 - + JDK8环境 - + @@ -1150,7 +1150,7 @@ public class StaticObjTest { 4、测试发现：三个对象的数据在内存中的地址都落在Eden区范围内，所以结论：**只要是对象实例必然会在Java堆中分配**。 - + > 1、0x00007f32c7800000(Eden区的起始地址) ---- 0x00007f32c7b50000(Eden区的终止地址) > @@ -1162,7 +1162,7 @@ public class StaticObjTest { 5、接着，找到了一个引用该staticObj对象的地方，是在一个java.lang.Class的实例里，并且给出了这个实例的地址，通过Inspector查看该对象实例，可以清楚看到这确实是一个java.lang.Class类型的对象实例，里面有一个名为staticobj的实例字段： - + 从《Java虚拟机规范》所定义的概念模型来看，所有Class相关的信息都应该存放在方法区之中，但方法区该如何实现，《Java虚拟机规范》并未做出规定，这就成了一件允许不同虚拟机自己灵活把握的事情。JDK7及其以后版本的HotSpot虚拟机选择把静态变量与类型在Java语言一端的映射Class对象存放在一起，**存储于Java堆之中**，从我们的实验中也明确验证了这一点 @@ -1217,7 +1217,7 @@ public class StaticObjTest { - + @@ -1271,7 +1271,7 @@ public class BufferTest { 直接占用了 1G 的本地内存 - + @@ -1281,13 +1281,13 @@ public class BufferTest { 原来采用BIO的架构，在读写本地文件时，我们需要从用户态切换成内核态 - + **直接缓冲区（NIO）** NIO 直接操作物理磁盘，省去了中间过程 - + ### 直接内存与 OOM @@ -1351,7 +1351,7 @@ Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory - + diff --git a/docs/JVM/JVM系列-第7章-对象的实例化内存布局与访问定位.md b/docs/JVM/JVM系列-第7章-对象的实例化内存布局与访问定位.md index dfa2b04..f0c3dab 100644 --- a/docs/JVM/JVM系列-第7章-对象的实例化内存布局与访问定位.md +++ b/docs/JVM/JVM系列-第7章-对象的实例化内存布局与访问定位.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第7章-对象的实例化内存布局与访问定位。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: debff71a date: 2020-11-14 19:38:42 --- @@ -36,7 +36,7 @@ date: 2020-11-14 19:38:42 - + ### 对象创建的方式 @@ -211,7 +211,7 @@ class Account{ 对象的内存布局 --------- - + @@ -242,7 +242,7 @@ class Account{ 图解内存布局 - + @@ -251,7 +251,7 @@ class Account{ **JVM是如何通过栈帧中的对象引用访问到其内部的对象实例呢？** - + 定位，通过栈上reference访问 @@ -262,7 +262,7 @@ class Account{ 1. 缺点：在堆空间中开辟了一块空间作为句柄池，句柄池本身也会占用空间；通过两次指针访问才能访问到堆中的对象，效率低 2. 优点：reference中存储稳定句柄地址，对象被移动（垃圾收集时移动对象很普遍）时只会改变句柄中实例数据指针即可，reference本身不需要被修改 - + @@ -271,4 +271,4 @@ class Account{ 1. 优点：直接指针是局部变量表中的引用，直接指向堆中的实例，在对象实例中有类型指针，指向的是方法区中的对象类型数据 2. 缺点：对象被移动（垃圾收集时移动对象很普遍）时需要修改 reference 的值 - \ No newline at end of file + \ No newline at end of file diff --git a/docs/JVM/JVM系列-第8章-执行引擎.md b/docs/JVM/JVM系列-第8章-执行引擎.md index beae0b9..a0386c5 100644 --- a/docs/JVM/JVM系列-第8章-执行引擎.md +++ b/docs/JVM/JVM系列-第8章-执行引擎.md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第8章-执行引擎。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: 408712f4 date: 2020-11-15 19:48:42 --- @@ -23,7 +23,7 @@ date: 2020-11-15 19:48:42 - + ### 执行引擎概述 @@ -34,7 +34,7 @@ date: 2020-11-15 19:48:42 3. JVM的主要任务是负责**装载字节码到其内部**，但字节码并不能够直接运行在操作系统之上，因为字节码指令并非等价于本地机器指令，它内部包含的仅仅只是一些能够被JVM所识别的字节码指令、符号表，以及其他辅助信息。 4. 那么，如果想要让一个Java程序运行起来，执行引擎（Execution Engine）的任务就是**将字节码指令解释/编译为对应平台上的本地机器指令才可以**。简单来说，JVM中的执行引擎充当了将高级语言翻译为机器语言的译者。 - + 1、前端编译：从Java程序员-字节码文件的这个过程叫前端编译 @@ -51,7 +51,7 @@ date: 2020-11-15 19:48:42 3. 当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息。 4. 从外观上来看，所有的Java虚拟机的执行引擎输入、处理、输出都是一致的：输入的是字节码二进制流，处理过程是字节码解析执行、即时编译的等效过程，输出的是执行过程。 - + @@ -71,18 +71,18 @@ Java代码编译和执行过程 - + 3. javac编译器（前端编译器）流程图如下所示： - + 4. Java字节码的执行是由JVM执行引擎来完成，流程图如下所示 - + @@ -105,7 +105,7 @@ Java代码编译和执行过程 **用图总结一下** - + 机器码 指令 汇编语言 ------------- @@ -164,7 +164,7 @@ Java代码编译和执行过程 - + @@ -193,7 +193,7 @@ Java代码编译和执行过程 2. 汇编过程：实际上指把汇编语言代码翻译成目标机器指令的过程。 - + @@ -211,7 +211,7 @@ Java代码编译和执行过程 3. 当一条字节码指令被解释执行完成后，接着再根据PC寄存器中记录的下一条需要被执行的字节码指令执行解释操作。 - + @@ -288,7 +288,7 @@ Java代码编译和执行过程 2. 在生产环境发布过程中，以分批的方式进行发布，根据机器数量划分成多个批次，每个批次的机器数至多占到整个集群的1/8。曾经有这样的故障案例：某程序员在发布平台进行分批发布，在输入发布总批数时，误填写成分为两批发布。如果是热机状态，在正常情况下一半的机器可以勉强承载流量，但由于刚启动的JVM均是解释执行，还没有进行热点代码统计和JIT动态编译，导致机器启动之后，当前1/2发布成功的服务器马上全部宕机，此故障说明了JIT的存在。—**阿里团队** - + @@ -317,7 +317,7 @@ public class JITTest { 通过 JVisualVM 查看 JIT 编译器执行的编译次数 - + @@ -369,7 +369,7 @@ public class JITTest { * 如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。 * 如果未超过阈值，则使用解释器对字节码文件解释执行 - + @@ -387,7 +387,7 @@ public class JITTest { 它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（Back Edge）。显然，建立回边计数器统计的目的就是为了触发OSR编译。 - + @@ -401,7 +401,7 @@ public class JITTest { - + diff --git a/docs/JVM/JVM系列-第9章-StringTable(字符串常量池).md b/docs/JVM/JVM系列-第9章-StringTable(字符串常量池).md index 95c3112..8932a72 100644 --- a/docs/JVM/JVM系列-第9章-StringTable(字符串常量池).md +++ b/docs/JVM/JVM系列-第9章-StringTable(字符串常量池).md @@ -8,7 +8,7 @@ categories: - 1.内存与垃圾回收篇 keywords: JVM，虚拟机。 description: JVM系列-第9章-StringTable(字符串常量池)。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/JVM/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/JVM/logo.png' abbrlink: ee2ba71e date: 2020-11-16 12:38:02 --- @@ -166,11 +166,11 @@ str 的内容并没有变：“test ok” 位于字符串常量池中的另一 4. 在JDK7中，StringTable的长度默认值是60013，StringTablesize设置没有要求 5. 在JDK8中，StringTable的长度默认值是60013，StringTable可以设置的最小值为1009 - + - + @@ -276,11 +276,11 @@ String 的内存分配 - + - + @@ -382,23 +382,23 @@ public class StringTest4 { 1、程序启动时已经加载了 2293 个字符串常量 - + 2、加载了一个换行符（println），所以多了一个 - + 3、加载了字符串常量 “1”~“9” - + 4、加载字符串常量 “10” - + 5、之后的字符串"1" 到 "10"不会再次加载 - + @@ -425,7 +425,7 @@ class Memory { 分析运行时内存（foo() 方法是实例方法，其实图中少了一个 this 局部变量） - + @@ -493,7 +493,7 @@ class Memory { IDEA 反编译 class 文件后，来看这个问题 - + @@ -929,7 +929,7 @@ public class StringNewTest { 5. `23 ldc #8 ` ：在字符串常量池中放入 “b”（如果之前字符串常量池中没有 “b” 的话） 6. `31 invokevirtual #9 ` ：调用 StringBuilder 的 toString() 方法，会生成一个 String 对象 - + @@ -988,13 +988,13 @@ JDK6 ：正常眼光判断即可 * new String() 即在堆中 * str.intern() 则把字符串放入常量池中 - + JDK7及后续版本，**注意大坑** - + @@ -1053,11 +1053,11 @@ public class StringExer1 { **JDK6** -![image-20201116113423492](https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.1.0/JVM/chapter_009/0015.png) +![image-20201116113423492](https://unpkg.zhimg.com/youthlql@1.0.8/JVM/chapter_009/0015.png) **JDK7/8** - + @@ -1080,7 +1080,7 @@ public class StringExer1 { } ``` - + **练习3** @@ -1169,11 +1169,11 @@ public class StringIntern2 { arr[i] = new String(String.valueOf(data[i % data.length])); ``` - + - + 2、使用 intern() 方法：由于数组中字符串的引用都指向字符串常量池中的字符串，所以程序需要维护的 String 对象更少，内存占用也更低 @@ -1182,11 +1182,11 @@ arr[i] = new String(String.valueOf(data[i % data.length])); arr[i] = new String(String.valueOf(data[i % data.length])).intern(); ``` - + - + @@ -1218,11 +1218,11 @@ public class StringGCTest { * Number of entries 和 Number of literals 明显没有 100000 * 以上两点均说明 StringTable 区发生了垃圾回收 - + - + diff --git a/docs/Java/Basis/Java8新特性.md b/docs/Java/Basis/Java8新特性.md index 967f898..8be81eb 100644 --- a/docs/Java/Basis/Java8新特性.md +++ b/docs/Java/Basis/Java8新特性.md @@ -9,7 +9,7 @@ categories: - 新特性 keywords: Java8，新特性，JDK8 description: 详解JDK8出现的新特性。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_Basis/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_Basis/logo.png' abbrlink: de3879ae date: 2020-10-19 22:15:58 --- @@ -20,7 +20,7 @@ date: 2020-10-19 22:15:58 > 本篇文章只讲解比较重要的 - + @@ -308,13 +308,13 @@ public class LambdaTest1 { **核心函数式接口** - + **其它函数式接口** - + @@ -902,7 +902,7 @@ Stream到底是什么呢？ - + @@ -1219,7 +1219,7 @@ public class StreamAPITest2 { ## 常用API - + diff --git a/docs/Java/Basis/泛型.md b/docs/Java/Basis/泛型.md index 051814e..6564813 100644 --- a/docs/Java/Basis/泛型.md +++ b/docs/Java/Basis/泛型.md @@ -9,7 +9,7 @@ categories: - 重难点 keywords: Java基础，泛型 description: 万字长文详解Java泛型。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_Basis/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_Basis/logo.png' abbrlink: adb2faf0 date: 2020-10-19 22:21:58 --- @@ -1038,7 +1038,7 @@ class Dog extends Animal { `test1()`在编译时就会飘红 - + @@ -1290,7 +1290,7 @@ public class Test_difference { } ``` - + ### 区别3：？通配符可以使用超类限定而T不行 diff --git a/docs/Java/collection/HashMap-JDK7源码讲解.md b/docs/Java/collection/HashMap-JDK7源码讲解.md index 3225448..491c288 100644 --- a/docs/Java/collection/HashMap-JDK7源码讲解.md +++ b/docs/Java/collection/HashMap-JDK7源码讲解.md @@ -8,7 +8,7 @@ categories: - HashMap keywords: Java集合，HashMap。 description: HashMap-JDK7源码讲解。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_Basis/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_Basis/logo.png' abbrlink: f1f58db2 date: 2020-11-01 10:21:58 --- @@ -202,7 +202,7 @@ hadoop2 大致是这样的一个结构 - + - 每个链表就算哈希表的桶（bucket） - 链表的节点值就算一个键值对 @@ -398,7 +398,7 @@ static class Entry implements Map.Entry { `HashMap`中的数组元素 & 链表节点 采用 `Entry`类实现 - + 1、一个正方形代表一个Entry对象，同时也代表一个键值对。 @@ -769,15 +769,15 @@ void transfer(Entry[] newTable, boolean rehash) { 大概画了一下图： - + - + - + - + @@ -871,7 +871,7 @@ void transfer(Entry[] newTable, boolean rehash) { **hashmap初始状态** - + @@ -897,7 +897,7 @@ void transfer(Entry[] newTable, boolean rehash) { **两个线程调用完毕之后，hashmap目前是这样的。** - + @@ -918,9 +918,9 @@ void transfer(Entry[] newTable, boolean rehash) { 3、来看下此时内存里的状态 - + - + ## 步骤4 @@ -957,7 +957,7 @@ void transfer(Entry[] newTable, boolean rehash) { 2、线程2直接**扩容完毕**，那么完成后的状态是这样【假设e2和e3还是hash到同一个位置】 - + 3、线程1还是原来的状态 @@ -967,11 +967,11 @@ void transfer(Entry[] newTable, boolean rehash) { 目前两个线程里的新数组是这样的 - + 为了方便后面观看，我画成这样。 - + @@ -1015,7 +1015,7 @@ void transfer(Entry[] newTable, boolean rehash) { 也就变成了下面这个样子。 - + @@ -1061,7 +1061,7 @@ void transfer(Entry[] newTable, boolean rehash) { 执行完，变成这样。 - + @@ -1077,7 +1077,7 @@ void transfer(Entry[] newTable, boolean rehash) { 3、执行pos_3： newTable[i] = e得到 newTable1[3] == e2 - + 这样就形成了循环链表，再get()数据就会陷入死循环。 diff --git a/docs/Java/collection/HashMap-JDK8源码讲解及常见面试题.md b/docs/Java/collection/HashMap-JDK8源码讲解及常见面试题.md index ea5a97c..e078a56 100644 --- a/docs/Java/collection/HashMap-JDK8源码讲解及常见面试题.md +++ b/docs/Java/collection/HashMap-JDK8源码讲解及常见面试题.md @@ -8,7 +8,7 @@ categories: - HashMap keywords: Java集合，HashMap。 description: HashMap-JDK8源码讲解及常见面试题。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_Basis/logo.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_Basis/logo.png' abbrlink: cbc5672a date: 2020-11-01 10:22:05 --- @@ -27,7 +27,7 @@ date: 2020-11-01 10:22:05 在JDK8中，优化了HashMap的数据结构，引入了红黑树。即HashMap的数据结构：数组+链表+红黑树。HashMap变成了这样。 - + ### 为什么要引入红黑树 @@ -456,7 +456,7 @@ Process finished with exit code 0 JDK8 hash的运算原理：高位参与低位运算，使得hash更加均匀。 - + @@ -569,7 +569,7 @@ JDK8 hash的运算原理：高位参与低位运算，使得hash更加均匀。 JDK8扩容时，数据在数组下标的计算方式 - + * `JDK8`根据此结论作出的新元素存储位置计算规则非常简单，提高了扩容效率。 diff --git a/docs/java_concurrency/Java并发体系-第一阶段-多线程基础知识.md b/docs/java_concurrency/Java并发体系-第一阶段-多线程基础知识.md index 26630e2..d70fdff 100644 --- a/docs/java_concurrency/Java并发体系-第一阶段-多线程基础知识.md +++ b/docs/java_concurrency/Java并发体系-第一阶段-多线程基础知识.md @@ -9,7 +9,7 @@ categories: - 原理 keywords: Java并发，原理，源码 description: 万字系列长文讲解Java并发-第一阶段-多线程基础知识。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_concurrency/logo_1.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_concurrency/logo_1.png' abbrlink: efc79183 date: 2020-10-05 22:40:58 --- @@ -31,13 +31,13 @@ date: 2020-10-05 22:40:58 概念：进程可进一步细化为线程，是一个程序内部的一条执行路径。 说明：线程作为CPU调度和执行的单位，每个线程拥独立的运行栈和程序计数器(pc)，线程切换的开销小。 - + 补充： - + 进程可以细化为多个线程。 每个线程，拥有自己独立的：栈、程序计数器 @@ -281,7 +281,7 @@ private void init(ThreadGroup g, Runnable target, String name, 1、多线程的设计之中，使用了代理设计模式的结构，用户自定义的线程主体只是负责项目核心功能的实现，而所有的辅助实现全部交由Thread类来处理。 2、在进行Thread启动多线程的时候调用的是start()方法，而后找到的是run()方法，但通过Thread类的构造方法传递了一个Runnable接口对象的时候，那么该接口对象将被Thread类中的target属性所保存，在start()方法执行的时候会调用Thread类中的run()方法。而这个run()方法去调用实现了Runnable接口的那个类所重写过run()方法，进而执行相应的逻辑。多线程开发的本质实质上是在于多个线程可以进行同一资源的抢占，那么Thread主要描述的是线程，而资源的描述是通过Runnable完成的。如下图所示： - + @@ -644,7 +644,7 @@ public void run() { 1、如果直接调用run()方法，相当于就是简单的调用一个普通方法。 - + 2、run()的调用是在start0()这个Native C++方法里调用的 @@ -654,11 +654,11 @@ public void run() { Java 线程在运行的生命周期中的指定时刻只可能处于下面 6 种不同状态的其中一个状态，这几个状态在Java源码中用枚举来表示。 - + 线程在生命周期中并不是固定处于某一个状态而是随着代码的执行在不同状态之间切换。Java 线程状态变迁如下图所示。 - + > 图中 wait到 runnable状态的转换中，`join`实际上是`Thread`类的方法，但这里写成了`Object`。 @@ -699,7 +699,7 @@ public static void main(String[] args) { 2、当JVM启动后，实际有多个线程，但是至少有一个非守护线程（比如main线程）。 - + - Finalizer：GC守护线程 @@ -1574,7 +1574,7 @@ volatile自己虽然不能保证原子性，但是和CAS结合起来就可以保 - + @@ -1782,7 +1782,7 @@ public Unsafe getUnsafe() throws IllegalAccessException { Unsafe的功能如下图： - + ## CAS相关 diff --git a/docs/java_concurrency/Java并发体系-第三阶段-JUC并发包-[1].md b/docs/java_concurrency/Java并发体系-第三阶段-JUC并发包-[1].md index 0bae6f6..5f64d41 100644 --- a/docs/java_concurrency/Java并发体系-第三阶段-JUC并发包-[1].md +++ b/docs/java_concurrency/Java并发体系-第三阶段-JUC并发包-[1].md @@ -9,7 +9,7 @@ categories: - 原理 keywords: Java并发，原理，源码 description: 万字系列长文讲解-Java并发体系-第三阶段-JUC并发包。JUC在高并发编程中使用频率非常高，这里会详细介绍其用法。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_concurrency/logo_1.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_concurrency/logo_1.png' abbrlink: 5be45d9e date: 2020-10-09 22:13:58 --- @@ -1869,7 +1869,7 @@ public class ForkJoinRecursiveAction { ForkJoinTask就是ForkJoinPool里面的每一个任务。他主要有两个子类：`RecursiveAction`和`RecursiveTask`。然后通过fork()方法去分配任务执行任务，通过join()方法汇总任务结果。 - + ## 小总结 diff --git a/docs/java_concurrency/Java并发体系-第三阶段-JUC并发包-[2].md b/docs/java_concurrency/Java并发体系-第三阶段-JUC并发包-[2].md index ed7bfef..f23695e 100644 --- a/docs/java_concurrency/Java并发体系-第三阶段-JUC并发包-[2].md +++ b/docs/java_concurrency/Java并发体系-第三阶段-JUC并发包-[2].md @@ -9,7 +9,7 @@ categories: - 原理 keywords: Java并发，原理，源码 description: 万字系列长文讲解-Java并发体系-第三阶段-JUC并发包。JUC在高并发编程中使用频率非常高，这里会详细介绍其用法。 -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_concurrency/logo_1.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_concurrency/logo_1.png' abbrlink: 70c90e5d date: 2020-10-10 22:13:58 --- @@ -563,7 +563,7 @@ public int getUnarrivedParties() 根据上面的代码，我们可以画出下面这个很简单的图： - + 这棵树上有 7 个 phaser 实例，每个 phaser 实例在构造的时候，都指定了 parties 为 5，但是，对于每个拥有子节点的节点来说，每个子节点都是它的一个 party，我们可以通过 phaser.getRegisteredParties() 得到每个节点的 parties 数量： @@ -952,7 +952,7 @@ public class ThreadPoolDemo { ## 线程池的底层工作流程 - + 1、创建线程池后，等待请求任务 @@ -1646,7 +1646,7 @@ public class ExecutorCompletionService implements CompletionService { **执行流程：** - + diff --git a/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[1].md b/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[1].md index 9bba188..a0cbdb1 100644 --- a/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[1].md +++ b/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[1].md @@ -9,7 +9,7 @@ categories: - 原理 keywords: Java并发，原理，源码 description: '万字系列长文讲解-Java并发体系-第二阶段,从C++和硬件方面讲解。' -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_concurrency/logo_1.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_concurrency/logo_1.png' abbrlink: 230c5bb3 date: 2020-10-06 22:09:58 --- @@ -291,7 +291,7 @@ d = e - f ; 由于处理器使用缓存和读写缓存冲区，这使得加载(load)和存储(store)操作看上去可能是在乱序执行，因为三级缓存的存在，导致内存与缓存的数据同步存在时间差。 - + @@ -343,7 +343,7 @@ int c = a + b; 冯诺依曼，提出计算机由五大组成部分，输入设备，输出设备存储器，控制器，运算器。 - + 输入设备：鼠标，键盘等等 @@ -367,7 +367,7 @@ int c = a + b; CPU的运算速度和内存的访问速度相差比较大。这就导致CPU每次操作内存都要耗费很多等待时间。内 存的读写速度成为了计算机运行的瓶颈。于是就有了在CPU和主内存之间增加缓存的设计。靠近CPU 的缓存称为L1，然后依次是 L2，L3和主内存，CPU缓存模型如图下图所示。 - + CPU Cache分成了三个级别: L1， L2， L3。级别越小越接近CPU，速度也更快，同时也代表着容量越小。速度越快的价格越贵。 @@ -377,7 +377,7 @@ CPU Cache分成了三个级别: L1， L2， L3。级别越小越接近CPU，速 3、L3 Cache是三级缓存中大的一级，例如12MB，同时也是缓存中慢的一级，在同一个CPU插槽 之间的核共享一个L3 Cache。 - + 上面的图中有一个Latency指标。比如Memory这个指标为59.4ns，表示CPU在操作内存的时候有59.4ns的延迟，一级缓存最快只有1.2ns。 @@ -409,7 +409,7 @@ Cache的出现是为了解决CPU直接访问内存效率低下问题的。 每一个线程有自己的工作内存，工作内存只存储该线程对共享变量的副本。线程对变量的所有的操 作(读，取)都必须在工作内存中完成，而不能直接读写主内存中的变量，不同线程之间也不能直接 访问对方工作内存中的变量。 - + Java的线程不能直接在主内存中操作共享变量。而是首先将主内存中的共享变量赋值到自己的工作内存中，再进行操作，操作完成之后，刷回主内存。 @@ -424,7 +424,7 @@ Java内存模型是一套在多线程读写共享数据时，对共享数据的 JMM内存模型与CPU硬件内存架构的关系： - + 工作内存：可能对应CPU寄存器，也可能对应CPU缓存，也可能对应内存。 @@ -434,9 +434,9 @@ JMM内存模型与CPU硬件内存架构的关系： ## 再谈可见性 - + - + 1、图中所示是 个双核 CPU 系统架构 ，每个核有自己的控制器和运算器，其中控制器包含一组寄存器和操作控制器，运算器执行算术逻辅运算。每个核都有自己的1级缓存，在有些架构里面还有1个所有 CPU 共享的2级缓存。 那么 Java 内存模型里面的工作内存，就对应这里的 Ll 或者 L2 存或者 CPU 寄存器。 @@ -452,7 +452,7 @@ JMM内存模型与CPU硬件内存架构的关系： 为了保证数据交互时数据的正确性，Java内存模型中定义了8种操作来完成这个交互过程，这8种操作本身都是原子性的。虚拟机实现时必须保证下面 提及的每一种操作都是原子的、不可再分的。 - + > (1)lock:作用于主内存的变量，它把一个变量标识为一条线程独占的状态。 > @@ -478,7 +478,7 @@ JMM内存模型与CPU硬件内存架构的关系： 如果没有synchronized，那就是下面这样的 - + @@ -589,7 +589,7 @@ volatile不保证原子性，只保证可见性和禁止指令重排 ## CPU术语介绍 - + @@ -717,7 +717,7 @@ public class VolatileExample { **1、下面是保守策略下，volatile写插入内存屏障后生成的指令序列示意图** - + > 图中的StoreStore屏障可以保证在volatile写之前，其前面的所有普通写操作已经对任 意处理器可见了。这是因为StoreStore屏障将保障上面所有的普通写在volatile写之前刷新到主内存。这里比较有意思的是，volatile写后面的StoreLoad屏障。此屏障的作用是避免volatile写与 后面可能有的volatile读/写操作重排序。因为编译器常常无法准确判断在一个volatile写的后面 是否需要插入一个StoreLoad屏障（比如，一个volatile写之后方法立即return）。为了保证能正确 实现volatile的内存语义，JMM在采取了保守策略：在每个volatile写的后面，或者在每个volatile 读的前面插入一个StoreLoad屏障。从整体执行效率的角度考虑，JMM最终选择了在每个volatile写的后面插入一个StoreLoad屏障。因为volatile写-读内存语义的常见使用模式是：一个 写线程写volatile变量，多个读线程读同一个volatile变量。当读线程的数量大大超过写线程时， 选择在volatile写之后插入StoreLoad屏障将带来可观的执行效率的提升。从这里可以看到JMM在实现上的一个特点：首先确保正确性，然后再去追求执行效率 @@ -725,7 +725,7 @@ public class VolatileExample { **2、下面是在保守策略下，volatile读插入内存屏障后生成的指令序列示意图** - + > 图中的LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。 LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。 上述volatile写和volatile读的内存屏障插入策略非常保守。在实际执行时，只要不改变volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障。 @@ -752,7 +752,7 @@ class VolatileBarrierExample { 针对readAndWrite()方法，编译器在生成字节码时可以做如下的优化 - + ​ 注意，最后的StoreLoad屏障不能省略。因为第二个volatile写之后，方法立即return。此时编译器可能无法准确断定后面是否会有volatile读或写，为了安全起见，编译器通常会在这里插入一个StoreLoad屏障。 @@ -766,7 +766,7 @@ class VolatileBarrierExample { X86处理器仅会对写-读操作做重排序。X86不会对读-读、读-写和写-写操作 做重排序，因此在X86处理器中会省略掉这3种操作类型对应的内存屏障。在X86中，JMM仅需在volatile写后面插入一个StoreLoad屏障即可正确实现volatile写-读的内存语义。这意味着在X86处理器中，volatile写的开销比volatile读的开销会大很多（因为执行StoreLoad屏障开销会比较大）。 - + diff --git a/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[2].md b/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[2].md index 25e0948..d441f9a 100644 --- a/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[2].md +++ b/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[2].md @@ -9,7 +9,7 @@ categories: - 原理 keywords: Java并发，原理，源码 description: '万字系列长文讲解-Java并发体系-第二阶段,从C++和硬件方面讲解。' -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_concurrency/logo_1.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_concurrency/logo_1.png' abbrlink: '8210870' date: 2020-10-07 22:10:58 --- @@ -18,7 +18,7 @@ date: 2020-10-07 22:10:58 # 可见性设计的硬件 - + 从硬件的级别来考虑一下可见性的问题 @@ -305,13 +305,13 @@ MESI协议规定了一组消息，就说各个处理器在操作内存数据的 - + ## MESI-优化 - + ​ MESI协议如果每次写数据的时候都要发送invalidate消息等待所有处理器返回ack，然后获取独占锁后才能写数据，那可能就会导致性能很差了，因为这个对共享变量的写操作，实际上在硬件级别变成串行的了。所以为了解决这个问题，硬件层面引入了写缓冲器和无效队列 @@ -449,7 +449,7 @@ int b = c; //load ## 相关术语 - + @@ -461,7 +461,7 @@ int b = c; //load **第一个机制是通过总线锁保证原子性。**如果多个处理器同时对共享变量进行读改写操作 （i++就是经典的读改写操作），那么共享变量就会被多个处理器同时进行操作，这样读改写操 作就不是原子的，操作完之后共享变量的值会和期望的不一致。举个例子，如果i=1，我们进行 两次i++操作，我们期望的结果是3，但是有可能结果是2，如图所示。 - + ​ 原因可能是多个处理器同时从各自的缓存中读取变量i，分别进行加1操作，然后分别写入 系统内存中。那么，想要保证读改写共享变量的操作是原子的，就必须保证CPU1读改写共享 变量的时候，CPU2不能操作缓存了该共享变量内存地址的缓存。 diff --git a/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[3].md b/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[3].md index 5212d5c..72fb78a 100644 --- a/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[3].md +++ b/docs/java_concurrency/Java并发体系-第二阶段-锁与同步-[3].md @@ -9,7 +9,7 @@ categories: - 原理 keywords: Java并发，原理，源码 description: '万字系列长文讲解-Java并发体系-第二阶段,从C++和硬件方面讲解。' -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_concurrency/logo_1.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_concurrency/logo_1.png' abbrlink: 113a3931 date: 2020-10-08 22:10:58 --- @@ -357,17 +357,17 @@ monitorexit释放锁。 monitorexit插入在方法结束处和异常处，JVM保 术语参考: http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html 在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。如下图所示： - + ## 对象头 当一个线程尝试访问synchronized修饰的代码块时，它首先要获得锁，那么这个锁到底存在哪里呢？是 存在锁对象的对象头中的。 HotSpot采用instanceOopDesc和arrayOopDesc来描述对象头，arrayOopDesc对象用来描述数组类型。instanceOopDesc的定义的在Hotspot源码的 instanceOop.hpp 文件中，另外，arrayOopDesc 的定义对应 arrayOop.hpp - + 从instanceOopDesc代码中可以看到 instanceOopDesc继承自oopDesc，oopDesc的定义载Hotspot 源码中的 oop.hpp 文件中。 - + - 在普通实例对象中，oopDesc的定义包含两个成员，分别是 _mark 和 _metadata @@ -383,21 +383,21 @@ monitorexit释放锁。 monitorexit插入在方法结束处和异常处，JVM保 Mark Word用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、 线程持有的锁、偏向线程ID、偏向时间戳等等，占用内存大小与虚拟机位长一致。Mark Word对应的类 型是 markOop 。源码位于 markOop.hpp 中。 - + - + 在64位虚拟机下，Mark Word是64bit大小的，其存储结构如下： - + 在32位虚拟机下，Mark Word是32bit大小的，其存储结构如下： - + 再加一个图对比一下，有一丁点的补充 - + @@ -447,7 +447,7 @@ Mark Word用于存储对象自身的运行时数据，如哈希码（HashCode） 线程在执行同步块之前，JVM会先在当前的线程的栈帧中创建一个`Lock Record`，其包括一个用于存储对象头中的 `mark word`（官方称之为`Displaced Mark Word`）以及一个指向对象的指针。下图右边的部分就是一个`Lock Record`。 - + @@ -571,7 +571,7 @@ synchronized(obj){ } ``` - + ## 轻量级锁什么时候升级为重量级锁？ @@ -608,7 +608,7 @@ synchronized(obj){ - 重量级锁的状态下，对象的`mark word`为指向一个堆中monitor对象的指针。一个monitor对象包括这么几个关键字段：cxq（下图中的ContentionList），EntryList ，WaitSet，owner。其中cxq ，EntryList ，WaitSet都是由ObjectWaiter的链表结构，owner指向持有锁的线程。 - + 在HotSpot虚拟机中，monitor是由ObjectMonitor实现的。其源码是用c++来实现的，位于HotSpot虚 拟机源码ObjectMonitor.hpp文件中(src/share/vm/runtime/objectMonitor.hpp)。ObjectMonitor主 要数据结构如下： @@ -661,7 +661,7 @@ ObjectMonitor() { 1、执行monitorenter时，会调用InterpreterRuntime.cpp (位于：src/share/vm/interpreter/interpreterRuntime.cpp) 的 InterpreterRuntime::monitorenter函 数。具体代码可参见HotSpot源码。 - + @@ -1147,7 +1147,7 @@ if (TryLock(Self) > 0) break ; 可以看到ObjectMonitor的函数调用中会涉及到Atomic::cmpxchg_ptr，Atomic::inc_ptr等内核函数， 执行同步代码块，没有竞争到锁的对象会park()被挂起，竞争到锁的线程会unpark()唤醒。这个时候就 会存在操作系统用户态和内核态的转换，这种切换会消耗大量的系统资源。所以synchronized是Java语 言中是一个重量级(Heavyweight)的操作。 用户态和和内核态是什么东西呢？要想了解用户态和内核态还需要先了解一下Linux系统的体系架构： - + 从上图可以看出，Linux操作系统的体系架构分为：用户空间（应用程序的活动空间）和内核。 内核：本质上可以理解为一种软件，控制计算机的硬件资源，并提供上层应用程序运行的环境。 用户空间：上层应用程序活动的空间。应用程序的执行必须依托于内核提供的资源，包括CPU资源、存 储资源、I/O资源等。 系统调用：为了使上层应用能够访问到这些资源，内核必须为上层应用提供访问的接口：即系统调用。 diff --git a/docs/java_concurrency/Java并发体系-第四阶段-AQS源码解读-[1].md b/docs/java_concurrency/Java并发体系-第四阶段-AQS源码解读-[1].md index 66bf896..0bd53bc 100644 --- a/docs/java_concurrency/Java并发体系-第四阶段-AQS源码解读-[1].md +++ b/docs/java_concurrency/Java并发体系-第四阶段-AQS源码解读-[1].md @@ -8,7 +8,7 @@ categories: - 原理 keywords: Java并发，AQS源码 description: '万字系列长文讲解-Java并发体系-第四阶段-AQS源码解读-[1]。' -cover: 'https://cdn.jsdelivr.net/gh/youthlql/lqlp@v1.0.0/Java_concurrency/logo_1.png' +cover: 'https://unpkg.zhimg.com/youthlql@1.0.8/Java_concurrency/logo_1.png' abbrlink: 92c4503d date: 2020-10-26 17:59:42 --- @@ -410,11 +410,11 @@ Process finished with exit code 0 **技术翻译：**是用来构建锁或者其它同步器组件的重量级基础框架及整个JUC体系的基石， 通过内置的FIFO队列来完成资源获取线程的排队工作，并通过一个int类变量`state`表示持有锁的状态。 - + - + AbstractOwnableSynchronizer AbstractQueuedLongSynchronizer @@ -426,7 +426,7 @@ AbstractQueuedSynchronizer AQS是一个抽象的父类，可以将其理解为一个框架。基于AQS这个框架，我们可以实现多种同步器，比如下方图中的几个Java内置的同步器。同时我们也可以基于AQS框架实现我们自己的同步器以满足不同的业务场景需求。 - + @@ -434,7 +434,7 @@ AQS是一个抽象的父类，可以将其理解为一个框架。基于AQS这 加锁会导致阻塞：有阻塞就需要排队，实现排队必然需要有某种形式的队列来进行管理 - + 1、抢到资源的线程直接使用办理业务，抢占不到资源的线程的必然涉及一种**排队等候机制**，抢占资源失败的线程继续去等待(类似办理窗口都满了，暂时没有受理窗口的顾客只能去候客区排队等候)，仍然保留获取锁的可能且获取锁流程仍在继续(候客区的顾客也在等着叫号，轮到了再去受理窗口办理业务）。 @@ -515,7 +515,7 @@ Node 的数据结构其实也挺简单的，就是 thread + waitStatus + pre + n ## AQS队列基本结构 - + 注意排队队列，不包括head（也就是后文要说的哨兵节点）。 @@ -583,7 +583,7 @@ public class AQSDemo { 以这样的一个实际例子说明。 - + @@ -765,7 +765,7 @@ public class AQSDemo { 2、C在if逻辑里准备入队，进行相应设置后，变成下面这样。 - + @@ -831,7 +831,7 @@ public class AQSDemo { 此时队列变成了下面的样子： - + 3、然后if结束之后，继续空的for循环，B线程开始了第二轮循环。 @@ -843,11 +843,11 @@ public class AQSDemo { 2、`node.prev = t`，进入if之后，让B节点的prev指针指向t，然后`compareAndSetTail(t, node)`设置尾节点 - + 3、CAS设置尾节点成功之后，执行if里的逻辑 - + @@ -1197,7 +1197,7 @@ protected final void setExclusiveOwnerThread(Thread thread) { - +