阿烈的博客

在过去15年（大约2010年至今），技术世界经历了翻天覆地的变化。移动端开发、比特币与区块链、Docker与云计算以及人工智能——正是这些变革的核心驱动力。

遗憾的是我经历了这些时代，参与其中却没有走在时代的前延，能熟练掌握却没有更深入到源码层次，并对这个时代产生更深远的影响。 就像移动端开发能搭建环境、跑通相应代码、了解基本开发原理，但没有真正上架一个自己的开发的app；能使用kubeadm从0搭建k8s生产环境，但未再此一步深入k8s源码并从理论到实践的转化并扩展到整个云原生生态。

比赛奖金和对战积分计算因项目而异，但通常基于比赛级别（重要性）和参赛成绩（名次、胜负），奖金是直接的经济回报，积分则影响世界/地区排名、种子排位及资格获取，高奖金赛事通常积分也高；

排名越高奖金越多，但具体分配规则因赛事而异：奖金池和个人/队伍的分配比例、排名对应奖金（如冠军、亚军、季军、八强、十六强）都不同，有的奖金甚至可达数千万甚至上亿美元。

本文介绍:

(1) 如何根据排名进行奖金分配才是合理的？

(2) 比赛的胜负如何影响选手(或队列)积分？

选择主要取决于你的应用对 “延迟（Latency）” 与 “吞吐量（Throughput）” 的权衡偏好

G1（Garbage-First）是 Java 虚拟机（JVM）中一款面向服务端应用的垃圾收集器，旨在为大内存机器提供高吞吐量且停顿时间可预测的内存回收能力。

jdk9及以后垃圾优先垃圾回收器是默认的垃圾回收器，因此通常无需执行任何额外操作。您可以通过 -XX:+UseG1GC命令行显式启用它。

G1 计划作为并发标记清除收集器 (CMS) 的长期替代方案。与 CMS 相比，G1 的一些差异使其成为更优的解决方案。其中一个区别在于 G1 是一种压缩式收集器。G1 的压缩程度足以完全避免使用细粒度的空闲列表进行内存分配，而是依赖于区域。这大大简化了收集器的部分功能，并基本消除了潜在的碎片问题。此外，与 CMS 收集器相比，G1 提供了更可预测的垃圾回收暂停时间，并允许用户指定所需的暂停目标。

CMS收集器(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。可以保证大部分工作都并发进行(应用不停止)，垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用。如：互联网站或B/S系统的服务端，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器非常符合这类应用的需求。

串行收集器使用单线程来执行所有的垃圾收集工作。
并行收集器（也称吞吐量收集器，Throughput Collector）使用多线程并行执行垃圾收集操作。

垃圾收集器需要处理的三个问题：
(1) 哪些对象需要回收?
(2) 什么时候回收垃圾对象?
(3) 如何回收垃圾对象?

Java虚拟机（JVM）提供了多种垃圾收集器（Garbage Collector, GC），每种收集器都有其独特的设计目标和权衡考量，以满足不同应用场景的需求。

编程语言引入垃圾回收（Garbage Collection, GC）机制的核心目的是为了自动化内存管理，从而解放程序员，让他们能够专注于编写程序逻辑，而不是手动管理内存的分配和释放。

点击 Linux学习笔记 查看在线版本。

本书通过 mdbook 发布。

这是我在2012年学习 Linux 的笔记。当前仅是linux基础部分，其它如多机房运维、集群等在中级篇(未发布)。