mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-08-14 05:21:42 +08:00
Compare commits
5 Commits
5a22a83859
...
274f6b90fa
Author | SHA1 | Date | |
---|---|---|---|
|
274f6b90fa | ||
|
540fa46005 | ||
|
7d3f3fa169 | ||
|
fe340aebb3 | ||
|
04f8df424e |
@ -56,8 +56,14 @@ tag:
|
||||
|
||||
### HTTP 基于 TCP 还是 UDP?
|
||||
|
||||
~~**HTTP 协议是基于 TCP 协议的**,所以发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。~~
|
||||
|
||||
**HTTP 协议是基于 TCP 协议的**,所以发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。
|
||||
🐛 修正(参见 [issue#1915](https://github.com/Snailclimb/JavaGuide/issues/1915)):HTTP 3.0 之前是基于 TCP 协议的,而 HTTP3.0 将弃用 TCP,改用 **基于 UDP 的 QUIC 协议** 。此变化主要为了解决 HTTP/2 中存在的队头阻塞问题。由于 HTTP/2 在单个 TCP 连接上使用了多路复用,受到 TCP 拥塞控制的影响,少量的丢包就可能导致整个 TCP 连接上的所有流被阻塞。
|
||||
|
||||
相关证明可以参考下面这两个链接:
|
||||
|
||||
- https://zh.wikipedia.org/zh/HTTP/3
|
||||
- https://datatracker.ietf.org/doc/rfc9114/
|
||||
|
||||
### 使用 TCP 的协议有哪些?使用 UDP 的协议有哪些?
|
||||
|
||||
|
@ -238,7 +238,7 @@ The content read from file:我是Guide。
|
||||
|
||||
### Writer(字符输出流)
|
||||
|
||||
`Writer`用于将数据(字符信息)写入到目的地(通常是文件),`java.io.Writer`抽象类是所有字节输出流的父类。
|
||||
`Writer`用于将数据(字符信息)写入到目的地(通常是文件),`java.io.Writer`抽象类是所有字符输出流的父类。
|
||||
|
||||
`Writer` 常用方法 :
|
||||
|
||||
|
@ -439,7 +439,7 @@ JDK1.8 默认使用的是 Parallel Scavenge + Parallel Old,如果指定了-XX:
|
||||
|
||||
- **并行与并发**:G1 能充分利用 CPU、多核环境下的硬件优势,使用多个 CPU(CPU 或者 CPU 核心)来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作,G1 收集器仍然可以通过并发的方式让 java 程序继续执行。
|
||||
- **分代收集**:虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆,但是还是保留了分代的概念。
|
||||
- **空间整合**:与 CMS 的“标记-清理”算法不同,G1 从整体来看是基于“标记-整理”算法实现的收集器;从局部上来看是基于“标记-复制”算法实现的。
|
||||
- **空间整合**:与 CMS 的“标记-清除”算法不同,G1 从整体来看是基于“标记-整理”算法实现的收集器;从局部上来看是基于“标记-复制”算法实现的。
|
||||
- **可预测的停顿**:这是 G1 相对于 CMS 的另一个大优势,降低停顿时间是 G1 和 CMS 共同的关注点,但 G1 除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为 M 毫秒的时间片段内。
|
||||
|
||||
G1 收集器的运作大致分为以下几个步骤:
|
||||
|
@ -291,7 +291,7 @@ finalize()是Object类的一个方法、一个对象的finalize()方法只会被
|
||||
|
||||
#### 3.4.4 分代收集算法
|
||||
|
||||
这种算法并没有什么新的思想,只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用“标记-清理”或者“标记-整理”算法来进行回收。
|
||||
这种算法并没有什么新的思想,只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用“标记-清除”或者“标记-整理”算法来进行回收。
|
||||
|
||||
说白了就是八仙过海各显神通,具体问题具体分析了而已。
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user