Prometheus

Prometheus是一个开源监控解决方案，用于收集和聚合指标作为时间序列数据。是继Kubernetes之后第二个CNCF托管项目

特点

普罗米修斯的主要特点是：

• 多维数据模型，其中时间序列数据由指标名称和键/值对标识
• PromQL，一种灵活的查询语言
• 不依赖分布式存储；单个服务器节点是自治的
• 时间序列收集通过 HTTP 上的 Pull 模型进行
• 通过中间网关支持推送时间序列
• 通过服务发现或静态配置发现Target
• 多种图形和仪表板支持

什么是指标？

指标是外行术语中的数值测量。术语时间序列是指随时间变化的记录。用户想要测量的内容因应用程序而异。对于 Web 服务器来说，它可能是请求时间；对于数据库，它可以是活动连接或活动查询的数量等。

指标在理解应用程序为何以某种方式运行方面发挥着重要作用。假设您正在运行一个 Web 应用程序并发现它很慢。要了解您的应用程序发生了什么，您将需要一些信息。例如，当请求数量较多时，应用程序可能会变慢。如果您有请求计数指标，则可以确定原因并增加处理负载的服务器数量。

更多信息

下面将会介绍常见开发语言如果集成到Prometheus监控体系中。

Java

在Java世界里，所有应用事实上可以简单的划分为两类：Spring应用和非Spring应用。Spring已经成为了事实上的Jakarta EE(Java EE)标准，所以本节会分别介绍Spring应用和非Spring应用如何集成Prometheus指标。

Micrometer

首先需要说明一下就是Micrometer，Micrometer是一个在JVM-Based应用中的一个供应商中立的应用可观测性门面(facade)，类似于slf4j。Micrometer支持常见的可观测性系统，包括Prometheus。

基本概念

Registry

每个应用都有一个MeterRegistry对象。是所有指标的注册表。

CompositeMeterRegistry

通过CompositeMeterRegistry，可以同时添加多个注册表，允许发布到多个监控系统

globalRegistry

一个静态全局注册表

Meter

监控中不同类型的指标，包括Timer、Counter、Gauge、DistributionSummary、LongTaskTimer、FunctionCounter、FunctionTimer和TimeGauge称作Meter。

命名约定

由于不同监控系统有不同的指标名约定，Micrometer建议使用小数点分割，然后会转换为目标监控系统推荐的命名约定，请看下面的例子：

1

registry.timer("http.server.requests");

在不同的监控系统中，会转换为推荐的名称：

1. Prometheus - http_server_requests_duration_seconds
2. Atlas - httpServerRequests
3. Graphite - http.server.requests
4. InfluxDB - http_server_requests

SpringBoot & Micrometer

首先创建一个SpringBoot项目，然后添加依赖

1
2
3
4

dependencies {
  implementation 'org.springframework.boot:spring-boot-starter-actuator'
  implementation 'io.micrometer:micrometer-registry-prometheus'
}

接下来编辑application.yaml，添加下面的配置：

1
2
3
4
5
6
7
8
9
10
11
12

spring:
  application:
    name: JavaMetricsDemo

management:
  endpoints:
    web:
      exposure:
        include: prometheus
  metrics:
    tags:
      application: ${spring.application.name}

首先，定义了应用的名称为JavaMetricsDemo，然后在management中开启prometheus端点暴露，接下来通过mertris配置给所有指标添加了一个自定义tagapplication=JavaMetricsDemo，方便区分

然后直接启动应用，访问http://localhost:8080/actuator/prometheus，即可看到默认情况下会暴露一些常见指标，jvm，tomcat，logback等。

暴露自定义指标

在实际开发中，自带的指标肯定是不够用的，需要手动添加一些业务、接口相关指标，参考下面的代码：

1
2
3
4
5
6
7
8
9
10

@RestController
public class DemoController {

  @Timed(value = "foo.time", description = "Time taken to return foo", histogram = true)
  @RequestMapping
  public String foo() {
    return "foo";
  }

}

我们创建了一个DemoController，然后定义了一个返回字符串的接口，注意我们在方法上面添加了**@Timed**注解，然后重新启动应用，观察指标变化

1
2
3
4
5
6
7
8
9
10

# HELP http_server_requests_seconds  
# TYPE http_server_requests_seconds summary
http_server_requests_seconds_count{application="JavaMetricsDemo",error="RuntimeException",exception="RuntimeException",method="GET",outcome="SERVER_ERROR",status="500",uri="/",} 2.0
http_server_requests_seconds_sum{application="JavaMetricsDemo",error="RuntimeException",exception="RuntimeException",method="GET",outcome="SERVER_ERROR",status="500",uri="/",} 0.0217194
http_server_requests_seconds_count{application="JavaMetricsDemo",error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="/",} 3.0
http_server_requests_seconds_sum{application="JavaMetricsDemo",error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="/",} 0.0175536
# HELP http_server_requests_seconds_max  
# TYPE http_server_requests_seconds_max gauge
http_server_requests_seconds_max{application="JavaMetricsDemo",error="RuntimeException",exception="RuntimeException",method="GET",outcome="SERVER_ERROR",status="500",uri="/",} 0.0203117
http_server_requests_seconds_max{application="JavaMetricsDemo",error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="/",} 0.0114682

由此我们可以知道，通过添加**@Timed**，可以获取接口响应时间相关指标，包含最大值，请求次数等。通过上述指标，可能会对服务健康提供一定帮助，也可以通过指标的tag精确到每个不同的接口请求。

接下来继续改造该类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

@RestController
public class DemoController {

  private final MeterRegistry meterRegistry;

  public JavaMetricsApplication(MeterRegistry meterRegistry) {
    this.meterRegistry = meterRegistry;
  }

  @PostConstruct
  public void init() {
    Counter.builder("foo.errors").description("Number of errors").register(meterRegistry);
  }

  @RequestMapping
  public String foo() {
    if (Math.random() > 0.5) {
      Counter counter = meterRegistry.counter("foo.errors");
      counter.increment();
      throw new RuntimeException("oops");
    }
    return "foo";
  }

}

通过IOC容器注入一个MeterRegistry，这就是上文说的每个应用的Registry对象，我们一般不需要手动创建，直接注入使用即可。

然后我们在init段中声明一个Counter类型的指标，这个过程建议单独放到一起，在应用启动时候注册到全局的Registry即可，然后我们获取一个叫foo.errors的Counter，用来统计错误次数，每当程序发生异常，就将次数加一。

再次启动应用，手动请求几次接口，重新查看指标页面

1
2
3

# HELP foo_errors_total Number of errors
# TYPE foo_errors_total counter
foo_errors_total{application="JavaMetricsDemo",} 3.0

可以看到我们新增的指标已经添加上来了

指标名和代码中的不同？

这里按照micrometer约定，因为micrometer是一个厂商中立的api，所以为了保持统一性，代码中所有指标统一用点分隔，在具体的provider中会自动转换成目标推荐的格式，这里就按照Prometheus的格式转换成了下划线，又因为是counter类型，所以最后添加了_total后缀。

总之，在代码中统一使用点分隔即可

到这里，演示了如何使用micrometer在一个Java应用中暴露指标接口和自定义指标，其他类型参考Counter用法即可。

Prometheus client_java

偶然发现Prometheus官方提供的clinet库从之前的simple_client换成了client_java，并且释出了1.0版本，这里也简单使用一下

快速开始

详情参考 quickstart

首先引入依赖

1
2
3

implementation 'io.prometheus:prometheus-metrics-core:1.0.0'
implementation 'io.prometheus:prometheus-metrics-instrumentation-jvm:1.0.0'
implementation 'io.prometheus:prometheus-metrics-exporter-httpserver:1.0.0'

• prometheus-metrics-core是指标库。
• prometheus-metrics-instrumentation-jvm提供开箱即用的 JVM 指标。
• prometheus-metrics-exporter-httpserver是一个用于公开 Prometheus 指标的独立 HTTP 服务器。

如果项目已经使用Servlet等，可以使用prometheus-exporter-servlet-jakarta

代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import io.prometheus.metrics.core.metrics.Counter;
import io.prometheus.metrics.exporter.httpserver.HTTPServer;
import io.prometheus.metrics.instrumentation.jvm.JvmMetrics;
import java.io.IOException;

public class App {
    public static void main(String[] args) throws InterruptedException, IOException {
        JvmMetrics.builder().register(); // initialize the out-of-the-box JVM metrics
        Counter counter = Counter.builder()
                .name("my_count_total")
                .help("example counter")
                .labelNames("status")
                .register();
        counter.labelValues("ok").inc();
        counter.labelValues("ok").inc();
        counter.labelValues("error").inc();
        HTTPServer server = HTTPServer.builder()
                .port(9400)
                .buildAndStart();
        System.out.println("HTTPServer listening on port http://localhost:" + server.getPort() + "/metrics");
        Thread.currentThread().join(); // sleep forever
    }
}

这是首先初始化了prometheus-metrics-instrumentation-jvm提供的自带的JVM指标，可以看到这里并没有Registry声明，因为通过这里可以看到client_java默认隐式使用了一个全局的Registry，并且也推荐只使用默认实现。

然后通过CounterBuilder创建了一个Counter指标，并且设置了几个样本值，最后在9400端口启动了一个Prometheus指标端点。

分析源码可以发现prometheus-metrics-exporter-httpserver默认使用了jdk HttpServer实现

然后需要解释一下这里的labelNames和labelValues是怎么使用的，这里给出一个下面例子，相信看完你就懂了：

1
2
3
4
5
6
7
8

Counter counter = Counter.builder()
                .name("my_count_total")
                .help("example counter")
                .labelNames("status", "path")
                .register();
        counter.labelValues("ok", "/foo").inc();
        counter.labelValues("ok", "/bar").inc();
        counter.labelValues("error", "/error").inc();

更多概念一文也无法讲清楚，若有需要推荐查看官网原文

Spring

目前client_java在2023年9月27日才发布1.0版本，所以目前官方还是推荐使用Micrometer方案。

非Spring项目中可考虑使用client_java和Micrometer皆可

其他语言

Prometheus提供了多种语言的SDK用来对应用可观测性指标收集，目前，官方支持的有：

• Go
• Java or Scala
• Python
• Ruby
• Rust

非官方支持：

• Bash
• C
• C++
• Common Lisp
• Dart
• Delphi
• Elixir
• Erlang
• Haskell
• Lua for Nginx
• Lua for Tarantool
• .NET / C#
• Node.js
• OCaml
• Perl
• PHP
• R

Shell是Linux/Unix的一个外壳，你理解成衣服也行。它负责外界与Linux内核的交互，接收用户或其他应用程序的命令，然后把这些命令转化成内核能理解的语言，传给内核，内核是真正干活的，干完之后再把结果返回用户或应用程序。

Linux/Unix提供了很多种Shell，为毛要这么多Shell？难道用来炒着吃么？那我问你，你同类型的衣服怎么有那么多件？花色，质地还不一样。写程序比买衣服复杂多了，而且程序员往往负责把复杂的事情搞简单，简单的事情搞复杂。牛程序员看到不爽的Shell，就会自己重新写一套，慢慢形成了一些标准，常用的Shell有这么几种，sh、bash、csh等，想知道你的系统有几种shell，可以通过以下命令查看：

1

cat /etc/shells

目前常用的 Linux 系统的默认 Shell 都是 bash，但是真正强大的 Shell 是深藏不露的 zsh， 绝对是马车中的跑车，跑车中的战斗机，史称『终极 Shell』，但是由于配置过于复杂，所以初期无人问津，很多人跑过来看看 zsh 的配置指南，什么都不说转身就走了。直到有一天，国外有个穷极无聊的程序员开发出了一个能够让你快速上手的zsh项目，叫做「oh my zsh」。这玩意就像「X天叫你学会 C++」系列，可以让你神功速成。

好，下面我们看看如何安装、配置和使用 zsh。

安装zsh

如果你用 Mac，就可以直接看下一节，默认就是zsh
如果你用 Ubuntu Linux，执行：

1

sudo apt install zsh

如果你用 Windows……去洗洗睡吧。

安装完成后设置当前用户使用 zsh：

1

chsh -s /bin/zsh

根据提示输入当前用户的密码就可以了。

安装oh my zsh

首先安装 git，安装方式同上。

1

sudo apt install git

安装「oh my zsh」可以自动安装也可以手动安装。

自动安装：

1

wget https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

手动安装：

1
2

git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc

都不复杂，安装完成之后退出当前会话重新打开一个终端窗口，看到终端提示符变化了，就代表安装完成了：

配置

zsh 的配置主要集中在用户当前目录的.zshrc里，用 vim 或你喜欢的其他编辑器打开.zshrc，在最下面会发现这么一行字：

# Customize to your needs…

可以在此处定义自己的环境变量和别名，当然，oh my zsh 在安装时已经自动读取当前的环境变量并进行了设置

zsh 的厉害之处在于不仅可以设置通用别名，还能针对文件类型设置对应的打开程序，比如：

1

alias -s html=gedit

意思就是你在命令行输入 hello.html，zsh会为你自动打开 gedit 并读取 hello.html

1

alias -s gz='tar -xzvf

表示自动解压后缀为 gz 的压缩包。

总之，只有想不到，没有做不到。

设置完环境变量和别名之后，基本上就可以用了，如果你是个主题控，还可以玩玩 zsh 的主题。在 .zshrc 里找到ZSH_THEME，就可以设置主题了，默认主题是：

ZSH_THEME=”robbyrussell”

oh my zsh 提供了数十种主题，相关文件在~/.oh-my-zsh/themes目录下，你可以随意选择，也可以编辑主题满足自己的变态需求

插件

oh my zsh 项目提供了完善的插件体系，相关的文件在~/.oh-my-zsh/plugins目录下，默认提供了100多种，可以根据自己的实际工作环境采用，想了解每个插件的功能，只要打开相关目录下的 zsh 文件看一下就知道了。插件也是在.zshrc里配置，找到plugins关键字，你就可以加载自己的插件了，系统默认加载 git ，你可以在后面追加内容，如下：

1

plugins=(git autojump mvn gradle)

使用

1、兼容 bash，原来使用 bash 的兄弟切换过来毫无压力，该咋用咋用。

2、强大的历史纪录功能，输入 grep 然后用上下箭头可以翻阅你执行的所有 grep 命令。

3、智能拼写纠正，输入gtep mactalk * -R，系统会提示：zsh: correct ‘gtep’ to ‘grep’ [nyae]? 比妹纸贴心吧，她们向来都是让你猜的……

4、各种补全：路径补全、命令补全，命令参数补全，插件内容补全等等。触发补全只需要按一下或两下 tab 键，补全项可以使用 ctrl+n/p/f/b上下左右切换。比如你想杀掉 java 的进程，只需要输入 kill java + tab键，如果只有一个 java 进程，zsh 会自动替换为进程的 pid，如果有多个则会出现选择项供你选择。ssh + 空格 + 两个tab键，zsh会列出所有访问过的主机和用户名进行补全

5、目录浏览和跳转：输入 d，即可列出你在这个会话里访问的目录列表，输入列表前的序号，即可直接跳转。

6、在当前目录下输入 .. 或 … ，或直接输入当前目录名都可以跳转，你甚至不再需要输入 cd 命令了。

7、通配符搜索：ls -l **/*.sh，可以递归显示当前目录下的 shell 文件，文件少时可以代替 find，文件太多就歇菜了。

8、更强的别名

9、插件支持

……

看完这篇文章，你就知道，zsh一出，无人再与争锋！终极二字不是盖的。

如果你是个正在使用 shell程序员，如果你依然准备使用 bash，那就去面壁和忏悔吧，别说你是程序员…

感谢那位开发了 oh my zsh 的无聊程序员，他可能没有因此收获物质上的利益，但是他的代码提升了无数程序员的效率，节省了大量的时间，我们说，程序员改变世界！

参考

zsh常用插件

zsh官方主题站

Google Guava Cache是一种非常优秀本地缓存解决方案，提供了基于容量，时间和引用的缓存回收方式，他的优点是封装了get，put操作；提供线程安全的缓存操作；提供过期策略；提供回收策略；缓存监控。当缓存的数据超过最大值时，使用LRU算法替换。这一篇我们将要谈到一个新的本地缓存框架：Caffeine Cache。它也是站在巨人的肩膀上-Guava Cache，借着他的思想优化了算法发展而来。

为什么需要本地缓存

相对于IO操作，速度快，效率高
相对于Redis，Redis是一种优秀的分布式缓存实现，但受限于网卡等原因，远水救不了近火

什么时候用

• 愿意消耗一些内存空间来提升速度
• 预料到某些键会被多次查询
• 缓存中存放的数据总量不会超出内存容量

怎么用

• 设置缓存容量
• 设置超时时间
• 提供移除监听器
• 提供缓存加载器
• 构建缓存

Why Caffeine

1. Caffine 在算法上的优点

常见的缓存淘汰算法还有LRU, FIFO, LFU:

LRU

LRU：最近最少使用算法，每次访问数据都会将其放在我们的队尾，如果需要淘汰数据，就只需要淘汰队首即可。仍然有个问题，如果有个数据在 1 分钟访问了 1000次，再后 1 分钟没有访问这个数据，但是有其他的数据访问，就导致了我们这个热点数据被淘汰。

LRU的优点和局限性：LRU可以很好的应对突发流量的情况，因为他不需要累计数据频率。但LRU通过历史数据来预测未来是局限的，它会认为最后到来的数据是最可能被再次访问的，从而给与它最高的优先级。

FIFO

FIFO：先进先出，在这种淘汰算法中，先进入缓存的会先被淘汰，会导致命中率很低。

LFU

LFU：最近最少频率使用，利用额外的空间记录每个数据的使用频率，然后选出频率最低进行淘汰。这样就避免了 LRU 不能处理时间段的问题。
上面三种策略各有利弊，实现的成本也是一个比一个高，同时命中率也是一个比一个好。Guava Cache虽然有这么多的功能，但是本质上还是对LRU的封装，如果有更优良的算法，并且也能提供这么多功能，相比之下就相形见绌了。

LFU的局限性：在 LFU 中只要数据访问模式的概率分布随时间保持不变时，其命中率就能变得非常高。比如有部新剧出来了，我们使用 LFU 给他缓存下来，这部新剧在这几天大概访问了几亿次，这个访问频率也在我们的 LFU 中记录了几亿次。但是新剧总会过气的，比如一个月之后这个新剧的前几集其实已经过气了，但是他的访问量的确是太高了，其他的电视剧根本无法淘汰这个新剧，所以在这种模式下是有局限性。

在现有算法的局限性下，会导致缓存数据的命中率或多或少的受损，而命中略又是缓存的重要指标。HighScalability网站刊登了一篇文章，由前Google工程师发明的W-TinyLFU: 一种现代的缓存 。Caffine Cache就是基于此算法而研发。Caffeine 因使用 Window TinyLfu 回收策略，提供了一个近乎最佳的命中率。

当数据的访问模式不随时间变化的时候，LFU的策略能够带来最佳的缓存命中率。然而LFU有两个缺点：

1. 它需要给每个记录项维护频率信息，每次访问都需要更新，这是个巨大的开销；

2. 如果数据访问模式随时间有变，LFU的频率信息无法随之变化，因此早先频繁访问的记录可能会占据缓存，而后期访问较多的记录则无法被命中。

因此，大多数的缓存设计都是基于LRU或者其变种来进行的。相比之下，LRU并不需要维护昂贵的缓存记录元信息，同时也能够反应随时间变化的数据访问模式。然而，在许多负载之下，LRU依然需要更多的空间才能做到跟LFU一致的缓存命中率。因此，一个“现代”的缓存，应当能够综合两者的长处。

使用

Maven

1
2
3
4
5

<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.1.2</version>
</dependency>

Gradle (Kotlin DSL)

1

implementation("com.github.ben-manes.caffeine:caffeine:3.1.2")

手动加载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public Object manulOperator(String key) {
    Cache<String, Object> cache = Caffeine.newBuilder()
        .expireAfterWrite(1, TimeUnit.SECONDS)
        .expireAfterAccess(1, TimeUnit.SECONDS)
        .maximumSize(10)
        .build();
    //如果一个key不存在，那么会进入指定的函数生成value
    Object value = cache.get(key, t -> setValue(key).apply(key));
    cache.put("hello",value);

    //判断是否存在如果不存返回null
    Object ifPresent = cache.getIfPresent(key);
    //移除一个key
    cache.invalidate(key);
    return value;
}

public Function<String, Object> setValue(String key){
    return t -> key + "value";
}

可配置项

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

initialCapacity=[integer]: 初始的缓存空间大小

maximumSize=[long]: 缓存的最大条数

maximumWeight=[long]: 缓存的最大权重

expireAfterAccess=[duration]: 最后一次写入或访问后经过固定时间过期

expireAfterWrite=[duration]: 最后一次写入后经过固定时间过期

refreshAfterWrite=[duration]: 创建缓存或者最近一次更新缓存后经过固定的时间间隔，刷新缓存

weakKeys: 打开key的弱引用

weakValues：打开value的弱引用

softValues：打开value的软引用

recordStats：开发统计功能

注意：

expireAfterWrite和expireAfterAccess同时存在时，以expireAfterWrite为准。

maximumSize和maximumWeight不可以同时使用

weakValues和softValues不可以同时使用

同步加载

构造Cache时候，build方法传入一个CacheLoader实现类。实现load方法，通过key加载value。

1
2
3
4
5
6
7

public Object syncOperator(String key){
    LoadingCache<String, Object> cache = Caffeine.newBuilder()
        .maximumSize(100)
        .expireAfterWrite(1, TimeUnit.MINUTES)
        .build(k -> setValue(key).apply(key));
    return cache.get(key);
}

异步加载

AsyncLoadingCache是继承自LoadingCache类的，异步加载使用Executor去调用方法并返回一个CompletableFuture。异步加载缓存使用了响应式编程模型。

如果要以同步方式调用时，应提供CacheLoader。要以异步表示时，应该提供一个AsyncCacheLoader，并返回一个CompletableFuture。

1
2
3
4
5
6
7
8
9
10
11
12
13

public Object asyncOperator(String key){
    AsyncLoadingCache<String, Object> cache = Caffeine.newBuilder()
        .maximumSize(100)
        .expireAfterWrite(1, TimeUnit.MINUTES)
        .buildAsync(k -> setAsyncValue(key).get());
    return cache.get(key);
}

public CompletableFuture<Object> setAsyncValue(String key){
    return CompletableFuture.supplyAsync(() -> {
        return key + "value";
    });
}

回收策略

Caffeine提供了3种回收策略：基于大小回收，基于时间回收，基于引用回收。

基于大小的过期方式

基于大小的回收策略有两种方式：一种是基于缓存大小，一种是基于权重。

1
2
3
4
5
6
7
8
9
10
11

// 根据缓存的计数进行驱逐
LoadingCache<String, Object> cache = Caffeine.newBuilder()
    .maximumSize(10000)
    .build(key -> function(key));


// 根据缓存的权重来进行驱逐（权重只是用于确定缓存大小，不会用于决定该缓存是否被驱逐）
LoadingCache<String, Object> cache1 = Caffeine.newBuilder()
    .maximumWeight(10000)
    .weigher(key -> function1(key))
    .build(key -> function(key));

maximumWeight与maximumSize不可以同时使用。

基于时间的过期方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// 基于固定的到期策略进行退出
LoadingCache<String, Object> cache = Caffeine.newBuilder()
    .expireAfterAccess(5, TimeUnit.MINUTES)
    .build(key -> function(key));
LoadingCache<String, Object> cache1 = Caffeine.newBuilder()
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .build(key -> function(key));

// 基于不同的到期策略进行退出
LoadingCache<String, Object> cache2 = Caffeine.newBuilder()
    .expireAfter(new Expiry<String, Object>() {
        @Override
        public long expireAfterCreate(String key, Object value, long currentTime) {
            return TimeUnit.SECONDS.toNanos(seconds);
        }

        @Override
        public long expireAfterUpdate(@Nonnull String s, @Nonnull Object o, long l, long l1) {
            return 0;
        }

        @Override
        public long expireAfterRead(@Nonnull String s, @Nonnull Object o, long l, long l1) {
            return 0;
        }
    }).build(key -> function(key));

Caffeine提供了三种定时驱逐策略：

expireAfterAccess(long, TimeUnit):在最后一次访问或者写入后开始计时，在指定的时间后过期。假如一直有请求访问该key，那么这个缓存将一直不会过期。expireAfterWrite(long, TimeUnit): 在最后一次写入缓存后开始计时，在指定的时间后过期。expireAfter(Expiry): 自定义策略，过期时间由Expiry实现独自计算。缓存的删除策略使用的是惰性删除和定时删除。这两个删除策略的时间复杂度都是O(1)。

基于引用的过期方式

Java中四种引用类型

引用类型被垃圾回收时间用途生存时间

1
2
3
4
5
6
7
8
9
10

// 当key和value都没有引用时驱逐缓存
LoadingCache<String, Object> cache = Caffeine.newBuilder()
    .weakKeys()
    .weakValues()
    .build(key -> function(key));

// 当垃圾收集器需要释放内存时驱逐
LoadingCache<String, Object> cache1 = Caffeine.newBuilder()
    .softValues()
    .build(key -> function(key));

注意：AsyncLoadingCache不支持弱引用和软引用。

Caffeine.weakKeys()：使用弱引用存储key。如果没有其他地方对该key有强引用，那么该缓存就会被垃圾回收器回收。由于垃圾回收器只依赖于身份(identity)相等，因此这会导致整个缓存使用身份 (==) 相等来比较 key，而不是使用 equals()。

Caffeine.weakValues() ：使用弱引用存储value。如果没有其他地方对该value有强引用，那么该缓存就会被垃圾回收器回收。由于垃圾回收器只依赖于身份(identity)相等，因此这会导致整个缓存使用身份 (==) 相等来比较 key，而不是使用 equals()。

Caffeine.softValues() ：使用软引用存储value。当内存满了过后，软引用的对象以将使用最近最少使用(least-recently-used ) 的方式进行垃圾回收。由于使用软引用是需要等到内存满了才进行回收，所以我们通常建议给缓存配置一个使用内存的最大值。softValues() 将使用身份相等(identity) (==) 而不是equals() 来比较值。

Caffeine.weakValues()和Caffeine.softValues()不可以一起使用。

移除事件监听

1
2
3
4

Cache<String, Object> cache = Caffeine.newBuilder()
    .removalListener((String key, Object value, RemovalCause cause) ->
                     System.out.printf("Key %s was removed (%s)%n", key, cause))
    .build();

写入外部存储

CacheWriter 方法可以将缓存中所有的数据写入到第三方。

1
2
3
4
5
6
7
8
9
10
11
12

LoadingCache<String, Object> cache2 = Caffeine.newBuilder()
    .writer(new CacheWriter<String, Object>() {
        @Override
        public void write(String key, Object value) {
            // 写入到外部存储
        }
        @Override
        public void delete(String key, Object value, RemovalCause cause) {
            // 删除外部存储
        }
    })
    .build(key -> function(key));

如果你有多级缓存的情况下，这个方法还是很实用。

注意：CacheWriter不能与弱键或AsyncLoadingCache一起使用。

统计

与Guava Cache的统计一样。

1
2
3
4

Cache<String, Object> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .recordStats()
    .build();

通过使用Caffeine.recordStats(), 可以转化成一个统计的集合. 通过 Cache.stats() 返回一个CacheStats。CacheStats提供以下统计方法：

1
2
3
4
5

hitRate(): 返回缓存命中率

evictionCount(): 缓存回收数量

averageLoadPenalty(): 加载新值的平均时间

缓冲区溢出

一种常见的状态破坏被称为缓冲区溢出。一般在栈中分配一个字符数组来保存一个字符串，但是字符串的长度超出了为数组分配的空间。就像下面这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// Implementation of library function gets()
char *gets(char *s)
{
    int c;
    char *dest = s;
    while ((c = getchar()) != '\n' && c != EOF)
        *dest++ = c;
    if (c == EOF && dest == s)
        return NULL;
    *dest++ = '\0';
    return s;
}
// Read input line and write it back
void echo()
{
    char buf[8]; // Way to small!!
    gets(buf);
    puts(buf);
}

这是库函数gets的一个实现。它从标准输入读入一行，在遇到一个回车换行字符或者某个错误情况时停止。然后把这个字符串复制到参数s指定的位置，并在结尾加上null字符。echo调用了这个函数然后送回到标准输出。

这个函数的问题是它没有办法确定字符串是否有足够的空间，我们将buf设置的比较小，这样任何长度超过7的字符串都会导致越界。

检查gcc为echo产生的汇编代码：

1
2
3
4
5
6
7
8

echo:
subq$24, %rsp;Allocate 24 bytes on stack
movq%rsp, %rdi;Compute buf as %rsp
callgets;Call gets
movq%rsp, %rdi;Compute buf as %rsp
callputs;Call puts
addq$24, %rsp;Deallocate stack space
ret;Return

该程序在栈上分配了24个字节。buf位于栈顶，然后把%rsp复制到%rdi作为调用gets和puts的参数。其中有16个字节未被使用。只要输入的字符串超过7个字节，过长的字符串就会覆盖栈上存储的某些信息。

在23个字符之前都没有严重的后果，但是超过以后就会破坏存储的返回位置，ret指令会导致程序跳转到一个完全意想不到的位置。

缓冲区溢出的更加致命的问题就是会让程序执行它本来不会执行的代码。这是一种最常见的通过计算机网络攻击系统安全的方法。通常，输入一个字符串，这个字符串包含一些可执行的字节编码，称为攻击代码，还有一些字节会用一个指向攻击代码的指针覆盖返回地址。那么，执行ret的效果就是跳转到攻击代码。

常见的攻击形式有两种：

• 使用系统调用启动一个shell程序给攻击者提供操作系统函数
• 执行一些未授权的任务，修复对栈的破坏，然后第二次执行ret指令，正常返回给调用者

对抗缓冲区溢出攻击

现代编译器和操作系统实现了很多机制，以避免遭受这样的攻击。

栈随机化

为了在系统中插入攻击代码，攻击者既要插入代码，也要插入指向这段代码的指针，这个指针也是攻击字符串的一部分。产生这个指针需要知道这个字符串放置的栈地址。在以前，程序的栈地址非常容易预测。对于所有运行同样程序和操作系统版本的系统来说，在不同的机器之间，栈的位置是相当固定的。因此攻击者可以确定一个常见的Web服务器所使用的栈空间，就可以设计一个在许多机器上都能实施的攻击。这种现象被称作安全单一化。

栈随机化的思想使得栈的位置在程序每次运行时都会有变化，这样在不同机器上执行同样的代码，他们的栈地址都是不同的。实现的方式是：程序开始时，在栈上分配一个0-n字节之间的随机大小的空间，程序不使用这段空间，但是它会导致每次执行后续的栈位置发生了变化。可以通过下面的代码确定栈的地址。

1
2
3
4
5

int main() {
    long local;
    printf("local at %p\n", &local);
    return 0;
}

在64位的操作系统上的范围大约是$2^{32}$。

在linux系统中，这类技术乘坐地址空间布局随机化(ASLR)，采用ASLR，每次运行时程序的不同部分，包括程序代码，库代码，栈，全局变量和堆数据，都会被加载到内存的不同区域。

但是这种技术也有漏洞，攻击者可以在攻击代码前插入很长的一段nop。这个指令唯一作用就是让PC加一，指向下一条指令。只要攻击者能够猜中这段序列的某个地址，程序就会“滑过”这个序列。

栈破坏检测

在最新的GCC中加入了一种栈保护者(stack protector)机制来检测缓冲区越界。其思想时在栈帧中任何布局缓冲区和栈状态之家存储一个特殊的金丝雀(canary)值，也称作哨兵值(guard value)，在程序每次运行时随机产生，因此攻击者没有简单的办法能知道它时什么。在恢复寄存器状态和从函数返回之前，会检查这个值是否被修改。如果是，那么程序异常中止。

可以通过-fno-stack-protector选项来阻止GCC产生这种代码。

栈保护很好地防止了缓冲区溢出攻击破坏存储在程序栈上的状态。它只会带来很小的性能损失，特别是GCC只在函数中有局部char类型缓冲区的时候才插入这样的代码。

限制可执行代码区域

典型的程序中，只有保存编译器产生的代码的那部分内存才需要是可执行的。其他部分被限制为只允许读和写。

有些类型的程序要求动态产生和执行代码的能力，比如使用JIT的Java动态的产生代码，以提高执行性能。是否能够将可执行代码限制在由编译器在创建原始程序时产生的那个部分中，取决于语言和操作系统。

什么是内存对齐

元素是按照定义顺序一个一个放到内存中去的，但并不是紧密排列的。从结构体存储的首地址开始，每个元素放置到内存中时，它都会认为内存是按照自己的大小（通常它为4或8）来划分的，因此元素放置的位置一定会在自己宽度的整数倍上开始，这就是所谓的内存对齐。

编译器为程序中的每个“数据单元”安排在适当的位置上。C语言允许你干预“内存对齐”。如果你想了解更加底层的秘密，“内存对齐”对你就不应该再模糊了。

例子

理论上，int占4byte，char占一个byte，将他们放在一个结构体里面，这个结构体应该占5byte，但是实际上却不是这样，这就是内存对齐导致的。

1
2
3
4
5
6
7
8
9
10

#include<stdio.h>
struct{
    int x;
    char y;
}Test;

int main() {
    printf("%d\n",sizeof(Test)); // 输出8不是5
    return 0;
}

为什么要内存对齐

1. 平台原因(移植原因)：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能在某些地址处取某些特定类型的数据，否则抛出硬件异常。
2. 性能原因：数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。

• 假如没有内存对齐机制，数据可以任意存放，现在一个int变量存放在从地址1开始的联系四个字节地址中，该处理器去取数据时，要先从0地址开始读取第一个4字节块,剔除不想要的字节（0地址）,然后从地址4开始读取下一个4字节块,同样剔除不要的数据（5，6，7地址）,最后留下的两块数据合并放入寄存器。这需要做很多工作。
• 现在有了内存对齐的，int类型数据只能存放在按照对齐规则的内存中，比如说0地址开始的内存。那么现在该处理器在取数据时一次性就能将数据读出来了，而且不需要做额外的操作，提高了效率。

内存对齐规则

1. 基本类型的对齐值就是其sizeof值;
2. 数据成员对齐规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员的对齐按照#pragma pack指定的数值和这个数据成员自身长度中，比较小的那个进行;
3. 结构(或联合)的整体对齐规则：在数据成员完成各自对齐之后，结构(或联合)本身也要进行对齐，对齐将按照#pragma pack指定的数值和结构(或联合)最大数据成员长度中，比较小的那个进行;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

struct {
    int i;    
    char c1;  
    char c2;  
}Test1;

struct {
    char c1;  
    int i;    
    char c2;  
}Test2;

struct {
    char c1;  
    char c2; 
    int i;    
}Test3;

int main() {
    printf("%d\n",sizeof(Test1));  // 输出8
    printf("%d\n",sizeof(Test2));  // 输出12
    printf("%d\n",sizeof(Test3));  // 输出8
    return 0;
}

默认#pragma pack(4)，且结构体中最长的数据类型为4个字节，所以有效对齐单位为4字节，下面根据上面所说的规则以第二个结构体来分析其内存布局： 首先使用规则1，对成员变量进行对齐：

• sizeof(c1) = 1 <= 4(有效对齐位)，按照1字节对齐，占用第0单元；
• sizeof(i) = 4 <= 4(有效对齐位)，相对于结构体首地址的偏移要为4的倍数，占用第4，5，6，7单元；
• sizeof(c2) = 1 <= 4(有效对齐位)，相对于结构体首地址的偏移要为1的倍数，占用第8单元；

然后使用规则2，对结构体整体进行对齐：

第二个结构体中变量i占用内存最大占4字节，而有效对齐单位也为4字节，两者较小值就是4字节。因此整体也是按照4字节对齐。由规则1得到s2占9个字节，此处再按照规则2进行整体的4字节对齐，所以整个结构体占用12个字节。

修改C语言对齐方式

更改C编译器的缺省字节对齐方式：

在缺省情况下，C编译器为每一个变量或是数据单元按其自然对界条件分配空间。一般地，可以通过下面的方法来改变缺省的对界条件：

• 使用伪指令#pragma pack (n)，C编译器将按照n个字节对齐。
• 使用伪指令#pragma pack ()，取消自定义字节对齐方式。

另外，还有如下的一种方式：

• __attribute((aligned (n)))，让所作用的结构成员对齐在n字节自然边界上。如果结构中有成员的长度大于n，则按照最大成员的长度来对齐。
• attribute((packed))，取消结构在编译过程中的优化对齐，按照实际占用字节数进行对齐。

不同平台上编译器的 pragma pack 默认值不同。而我们可以通过预编译命令#pragma pack(n), n= 1,2,4,8,16来改变对齐系数。

例如，对于上个例子的三个结构体，如果前面加上#pragma pack(1)，那么此时有效对齐值为1字节，此时根据对齐规则，不难看出成员是连续存放的，三个结构体的大小都是6字节。

修改C++内存对齐方式

c++11以后引入两个关键字 alignas与 alignof。其中alignof可以计算出类型的对齐方式，alignas可以指定结构体的对齐方式。

但是alignas在某些情况下是不能使用的，具体见下面的例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

struct Info {
  uint8_t a;
  uint16_t b;
  uint8_t c;
};

std::cout << sizeof(Info) << std::endl;   // 6  2 + 2 + 2
std::cout << alignof(Info) << std::endl;  // 2

struct alignas(4) Info2 {
  uint8_t a;
  uint16_t b;
  uint8_t c;
};

std::cout << sizeof(Info2) << std::endl;   // 8  4 + 4
std::cout << alignof(Info2) << std::endl;  // 4

区别

• #pragma pack (n)指定的是全局的内存对齐方式
• alignas的粒度更小，修饰在结构体上就是指定结构体的内存对齐方式，修饰在变量上就是指定变量的内存对齐方式