在使用相关的JVM内存工具查看堆栈情况时， 有两个指标Shallow Size和Shallow Size不是很清楚其真正含义，现在通过一个例子来了解其含义。 先说一下概念描述： shallow size: 对象自身占用的内存, 不包括它引用的其他实例。例如，对于一个简单的对象，如果它有几个基本数据类型的字段和对其他对象的引用，那么该值只计算这些字段所占的空间，而不计算被引用对象的空间 retained size: 当实例A被回收时, 可以同时被回收的实例的Shallow Size之和 示例代码很简答， 构造一个List，然后插入100万个元素， 在程序运行的过程中使用IDEA自带的Profiler来获取堆栈快照，后面的一个无限循环是为了防止程序运行完终止。 12345678910public static void main(String[] args) throws Exception { List<Integer> l = new ArrayList<>(); for (int i=0; i < 1000000; i++ ...

先说一下我的环境与配置： 域名：在namesilo上购买的 证书使用方式：nginx nginx部署方式：docker 说一下在使用过程中可能会遇到的一些坑， 方便后来人正确处理。 安装脚本过程安装acme.sh前要将系统用户切换到和nginx服务使用的用户， 否则之后的relaod命令将没有权限执行。 比如我使用root用户安装的docker启动nginx, 就切换到root，并在此用户下安装acme.sh 生成证书过程此处使用的是dns的api方式来验证，有几个点需要注意。 生成api key的时候，Generate key for read-only access 一定不要勾选 如果第一次没有注意勾选，并且使用脚本生成证书（不管是否生成失败），在新生成key之后， 需要先将.acme.sh account.conf Namesilo_Key 删除掉

今天在公交上，一个应该是初中或高中的学生，让我帮忙弄一下行李箱，叫我 “叔叔”， 这好像是我印象中第一次有陌生人叫我这个称呼，看来是真老了。 但我的人生还有许多事没做，必须加紧步伐，把有限的时间花费在更有意义的事情上。 同时， 更重要的一点是身体，要加强锻炼，才能更好的应付之后可能发生的事。 希望今年心想事成，最重要的结婚和工作的事都能如意。

什么是指针 一个变量，指向了另外一个变量的内存地址。 指针变量通常用于引用其他变量的内存地址，以便能够直接访问或修改该变量的值。 指针用法 * 声明变量类型为指针；或者使用指针访问变量的值 & 指针指向的内存地址， 也是将一个普通变量赋值给一个指针变量的方式 1234567891011121314151617181920212223package mainimport "fmt"func main() { var a int= 20 /* 声明实际变量 */ var ip *int /* 声明指针变量 */ ip = &a /* 指针变量的存储地址 */ fmt.Printf("a 变量的地址是: %x\n", &a ) /* 指针变量的存储地址 */ fmt.Printf("ip 变量储存的指针地址: %x\n", ip ) /* 使用指针访问值 */ fmt.Printf("*ip 变量的值: %d\n" ...

pve中一块nvme磁盘最近偶尔会报温度过高， 所以需要加个监控， 之前已经装过node_expoter, 但是其磁盘硬件监控这一块的信息不够全面，其更多强调的是磁盘的性能，比如IO等。 温度监控这一块也有， 但是不够直观明显，而且缺少其他的一些磁盘硬件本身的信息， 下图是node_exporter监控硬件温度，在Hardware Misc里的Hardware temperature monitor中的显示信息： 基于此， 需要一个专门用来收集磁盘硬件本身信息的exporter, prometheus提供了一个基于smart ctl的exporter, 地址是https://github.com/prometheus-community/smartctl_exporter 因为这是直接监控硬件的， 所以我是直接安装在宿主机上的（包括之前的node_exporter)， 没有安装在虚拟机上。 smartctl _exporter安装 进入 https://github.com/prometheus-community/smartctl_exporter/releases下载自己机器需 ...

先说一下整体的环境和安装方式 pve虚拟机专门开了一个lxc容器，用于安装tailscale，并利用此容器转发流量到局域网内的其他机器上，实现外部访问内网所有机器 由于tailscale本身的中转服务器derp没有中国的节点，最近的节点是位于东京的，所以此处选择自己搭建一个中继节点 PVE LXC安装tailscale此处的lxc模板使用的是Debian 11(bullseye)。 创建一个非特权的CT容器， 模板选择Debian 11(bullseye)，其他配置都使用默认配置（网络那儿最好选择DHCP，让路由器自动分配一个IP） 安装完成后， 先不要启动，需要修改一些配置 在pve宿主机中，获取信息， 执行命令和返回结果如下, 记录 10, 200 这两个数字, 后面需要用到 12root@pve:~# ls -al /dev/net/tuncrw-rw-rw- 1 root root 10, 200 Jun 30 23:08 /dev/net/tun 在pve宿主机中，修改 /etc/pve/lxc/CTID.conf文件， 新增如下两行：其中10和200是上一步中获 ...

有这样一个场景， 我们在e这个包下， 有一个err_code.go文件，在其中自定义了一个错误码结构体和一些错误码，内容如下: 1234567891011package etype ErrCode struct { Code int Msg string}var ( Success = ErrCode{Code: 10000, Msg: ""} UnknownErr = ErrCode{Code: 10001, Msg: "未知错误"} InvalidParams = ErrCode{Code: 10002, Msg: "参数不合法"}) 现在我们想获取到所有这些预先定义的错误码的code，应该如何做呢？ 可以借助go标准库中AST语法树的能力遍历所有变量，然后过滤得到我们想要的变量类型， 具体代码如下： 1234567891011121314151617181920212223242526272 ...

Mysql的默认隔离级别是可重复读。并且在该级别下， 也不会出现幻读（一般意义上的可重复读是存在幻读的）， 那么Mysql是如何实现的呢？ 不可重复读的解决方案 不可重复读定义：在同一个事务中， 前后两次相同的查询， 返回的结果不一样， 针对的是 update 的操作 结论：通过使用MVCC实现不可重复读。 每个事务在开始的时候， 都会创建一个递增的当前事务版本号。 mysql中每条记录都有两个隐藏字段：创建版本号create_version和删除版本号delete_version。 当记录被insert的时候， 创建版本号就是当前事务的版本号， 删除版本号为null 当记录被delete的时候， 将删除版本号设置为当前事务的版本号 当记录被update的时候， 先进行delete，然后再进行add 对于update的操作， 举例说明一下， 假设刚开始的表数据如下： id name create_version delete_version 1 小明 1 NULL 2 小红 3 NULL 现在要执行如下sql， 假设执行此sql的事务版本号为10: updat ...

首先理解一下哈希函数的意思。 哈希函数 将任意长度的数据映射到有限长度的域上。 本质是对一段数据m进行杂糅，然后输出另一段固定长度的数据h，并将这个h作为这段数据的特征值。 基本原理就是将数据块m分成多段，每一段长度固定（如128位），若某段长度不足，则进行补位（如0或者1），然后对每一块都进行hash运算，再将这些数据进行迭代（比如相邻两段进行异或），最终得到一个数据。 普通哈希取模先来看一下普通哈希取模是什么样的？ 1c = hash(key) % n 其中n为节点数目，计算得到的c为对应的节点编号。 假设现在总共有A，B，C三台服务器节点， 现在对某个key值哈希之后得到的值为5， 则c = 5 % 4 = 1, 表示该值存储在B节点上。 现在若需要增加一台服务器节点D，则此时c=5 % 5 = 0，表明该值存储在A服务器上，前后就会出现不一致。 这样当出现服务器新增、删除、宕机的时候，这样就会请求后端数据库，造成缓存穿透。因此普通的哈希取模定位key所在的服务器的方法会有问题。 综上， 普通哈希最大的缺点就是在扩容或缩容的时候， 会造 ...

以下都是针对InnoDb引擎， 描述的都是单机事务，说明一下个人对事务的一些理解。 事务的四大特性这四个特性并不是平级的关系。准确的说， 一致性是最基本的属性，其他的属性都是为了保证一致性而存在的。 Atomicity 原子性 整个事务是一个整体，是程序运行时不可分割的最小工作单位。 一个事务中的所有操作要么全部执行成功，要么全部都不执行。任何一条语句执行失败，都会导致事务回滚。 实现方式：undo log，当执行失败的时候，使用undo log进行回滚。 Isolation 隔离性 一个事务所做的修改在该事务未提交之前，对其他事务不可见。 为什么会出现隔离性的需求？ 本质是因为并发， 试想一下， 如果没有并发，所有事务都是串行执行的，那么也就不会存在隔离性的问题了。所以mysql提出了隔离级别的概念， 针对不同的隔离级别，进行不同的处理， 这在下文的隔离级别会有详细描述。 那么， 如何解决并发造成的数据一致性问题？ 第一个想法自然是加锁，给数据加锁，相当于让各个事务串行执行，自然就不存在数据一致性的问题了。同时为了提高加锁的效率和粒度，mysql针对锁提出了不同的类别，比如间 ...