<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Anonymous&#39; Blog</title>
    <link>https://huweicai.com/</link>
    <description>Recent content on Anonymous&#39; Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zn-Hans</language>
    <lastBuildDate>Sat, 12 Jul 2025 19:58:00 +0800</lastBuildDate>
    
	<atom:link href="https://huweicai.com/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>一些有意思的C&#43;&#43;代码</title>
      <link>https://huweicai.com/cpp-fun-codes/</link>
      <pubDate>Sat, 12 Jul 2025 19:58:00 +0800</pubDate>
      
      <guid>https://huweicai.com/cpp-fun-codes/</guid>
      <description>三行情诗 谁说我们写 C++ 的就不懂浪漫了： // 我的心必须通过&amp;quot;爱你&amp;quot;的约束才能实例化 template&amp;lt;typename Heart&amp;gt; requires loves&amp;lt;Heart, You&amp;gt; // 激情、忠诚、永恒置入爱的元组，这份爱在编译时就已确定，不会因运行时的变化而改变 // 是写在源码里的承诺，是嵌入二进制的誓言 constexpr auto my_feelings = std::tuple{passion, devotion, eternity}; // 在 C++ 的类型系统中，我们的未来被特化为永远为真，这是编译器都认可的事实 template&amp;lt;&amp;gt; struct future&amp;lt;us&amp;gt; : std::true_type { static constexpr auto value = forever; }; 不愧是我们写 C++ 的，写出来的情诗都能是零运行时开销的。 AND 下面这段代</description>
    </item>
    
    <item>
      <title>如何极致地压榨一颗 CPU 核心</title>
      <link>https://huweicai.com/cpu-996/</link>
      <pubDate>Mon, 05 May 2025 19:58:00 +0800</pubDate>
      
      <guid>https://huweicai.com/cpu-996/</guid>
      <description>通常当服务端工程师谈论 CPU 核心的时候，更多地时候在乎的是数量而不是质量，比如我们开发了一个 Java 服务的容器需要申请一个 4 核 32 GB 内存的套餐（4C32G），还开发了一个 Golang 服务需要 4C8G 的 quota（我真的不是在黑 Java），但我们绝大多数时候并不会关心底层的 4 个核心来自于 AMD 还是 Intel 品牌的 CPU， 更别说具体什么 Xeon 还是 EPYC 型号了。 因为大部分服务端的问题都可以水平扩容来得到解决，四颗核心不够了，那我们申请六颗核心就好了，</description>
    </item>
    
    <item>
      <title>数据的蒲公英——组播</title>
      <link>https://huweicai.com/multicast/</link>
      <pubDate>Tue, 22 Oct 2024 20:47:00 +0800</pubDate>
      
      <guid>https://huweicai.com/multicast/</guid>
      <description>组播与单播 组播(Multicast，又称群播、多播) 与单播 (Unicast) 都是数据传输的一种方式，如果要映射现实世界中的信息传递方式，单播可以类比为打电话，有人呼出电话然后有人接听，然后他们互相畅谈最后互道再见；而组播则更加类似于广播，电台的主播会在收音机的那一头说话，所有打开收音机的人都可以收到，你也可以随时关闭收音机，只能单方面的听到来自对方的声音。 虽然今天到处都是打电话的人，而我们已经很少能在身边看到广播</description>
    </item>
    
    <item>
      <title>动态链接函数调用是如何实现的</title>
      <link>https://huweicai.com/dynamic-linking/</link>
      <pubDate>Sun, 30 Jun 2024 01:26:00 +0800</pubDate>
      
      <guid>https://huweicai.com/dynamic-linking/</guid>
      <description>函数链接 根据函数在编译期间的链接方式， 我们可以将函数分为三种： 直接调用（Direct Call）：这是最直接的一种方式，函数地址在编译时就已经确定，调用时直接跳转到目标地址。 静态链接（Static Linking）：在编译时将库与程序合并，尽管在单个编译单元内不确定函数的具体地址，但在链接阶段会解析所有符号，最终生成的可执行文件包含所有必要的代码，无需依赖外部库。 动态链接（Dynamic Linking</description>
    </item>
    
    <item>
      <title>C/C&#43;&#43; &amp; Python 融合之道</title>
      <link>https://huweicai.com/c-with-python-intercall/</link>
      <pubDate>Mon, 29 Jan 2024 09:50:00 +0800</pubDate>
      
      <guid>https://huweicai.com/c-with-python-intercall/</guid>
      <description>Python 解释器 正如软件系统通常分为定义与实现两部分，编程语言也是。 比如 C++ 标准是由国际标准化组织 ( ISO ) 下属的 ISO/IEC JTC1/SC22/WG21特别工作组制定的，最新标准为 C++ 20 (ISO/IEC 14882:2020)，这是定义；而其实现则有 GNU 的 gcc、微软的 visual c++、Apple 发起的 clang 等等，任何人都可以按照定义去实现自己的实现。 Java 规范则是由 Oracle 主导的 JCP 所制定，有 Oracle Java SE、OpenJDK、Corretto、AdoptOpen 等大量</description>
    </item>
    
    <item>
      <title>Executable and Linkable Format</title>
      <link>https://huweicai.com/elf/</link>
      <pubDate>Sat, 07 Oct 2023 13:58:00 +0800</pubDate>
      
      <guid>https://huweicai.com/elf/</guid>
      <description>ELF Executable and Linkable Format，可执行与可链接格式，其一个很熟悉的身份就是 Linux 操作系统的标准可执行文件格式，在 Linux 上运行我们编写的代码时，就需要将其编译成 ELF 格式。 另外它还定义了共享库和核心转储文件的结构和布局。 ELF 文件格式在操作系统中起着重要的作用，它使得我们编写的代码能够被正确地编译、链接和执行。 此外，部分 Unix 系统，如: Solaris、FreeBSD 等也采用 ELF 作为其可执行文件格式。 ELF 文件格式被设计为可扩展和灵活的</description>
    </item>
    
    <item>
      <title>很快的共享内存</title>
      <link>https://huweicai.com/shared-memory/</link>
      <pubDate>Tue, 08 Aug 2023 13:42:00 +0800</pubDate>
      
      <guid>https://huweicai.com/shared-memory/</guid>
      <description>WHY 共享内存 进程间通信有许多种方式，不同的场景有不同的选择。 当通信内容非常简单的时候，可以考虑信号、信号量甚至 flock() 这种最基础的通信方式。 当需要传递不仅仅是信号这种规模的数据时，可以考虑 FIFO、MQ 等内核 API，也非常的简单易用 。 当我们的传输内容再进一步复杂，需要用“协议”去抽象这种复杂度的时候，Unix Domain Socket 会是一个不错的选择，比如常见的 gRPC over UDS；或者牺牲一点网络栈开销，直接使用基于 TCP / UDP 的 Socket 也非常</description>
    </item>
    
    <item>
      <title>Linux Kernel Debug Tips</title>
      <link>https://huweicai.com/kernel-debug-tips_en/</link>
      <pubDate>Tue, 17 Jan 2023 00:00:00 +0800</pubDate>
      
      <guid>https://huweicai.com/kernel-debug-tips_en/</guid>
      <description>Kernel Kernel undertakes the core Operating System job, which is the foundation of the current software ecosystem.
So, knowing more about how the kernel works will contribute to the construction of our user mode system.
The best method to learn software code is debugging while watching, software = code + data, know more about the runtime data while learning code can help us understand it better.
However the Kernel is not a normal software system, we can&amp;rsquo;t add breakpoint and debug it through IDE debug button like other normal software, though we can implement it by kgdb + QEMU, it&amp;rsquo; still too heavy, and not available for online systems.
This article shares two lightweight kernel debugging tips, helps us observing it runtime status rapidly.
Kernel Module Usally, our codes are runing in user mode. In Linux operating systems, the instruction of user mode program will run in level Ring 3 , they do not have the permission to acces the data in level Ring 0 high memory address space, which means that they can&amp;rsquo;t snoop the data inside Kernel.
In that case, why not try to run our code inside the Kernel?
It&amp;rsquo;s possible to edit the source code of kernel, adding log to print the information we concerned, but it&amp;rsquo;s a long tedious step.</description>
    </item>
    
    <item>
      <title>CubeFS&amp;Kubernetes实践</title>
      <link>https://huweicai.com/cubefs-with-kubernetes/</link>
      <pubDate>Thu, 22 Dec 2022 20:47:00 +0800</pubDate>
      
      <guid>https://huweicai.com/cubefs-with-kubernetes/</guid>
      <description>Kubernetes （K8S） 是目前容器编排领域事实上的标准，在全球范围内有着广泛的应用。 CubeFS 既可以在 K8S 集群中部署客户端，通过 CSI 接口为 K8S 提供持久卷存储能力，也可以直接将 CubeFS 服务端集群整个部署在 K8S 中。 本文将分别介绍一下如何在 K8S 集群中部署 CubeFS 客户端、服务端，以及一些常见的运维操作和注意事项。 服务端 随着容器化的普及，基础设施全部上 K8S 是未来的趋势，这样所有的资源可以统一调度，且有着云原生庞大生态的加持，基础设施的运维成本也将大幅</description>
    </item>
    
    <item>
      <title>聊一聊磁盘</title>
      <link>https://huweicai.com/something-about-disk/</link>
      <pubDate>Mon, 13 Jun 2022 18:20:55 +0800</pubDate>
      
      <guid>https://huweicai.com/something-about-disk/</guid>
      <description>磁盘 在计算机发展的历程中，存储设备的演进一直是一个引人入胜的故事。 从最早的打孔纸带，到磁性存储，再到今天的固态硬盘，人们一直在追求更快、更大、更可靠的数据存储方案。 在这个演进过程中，磁盘凭借着断电数据不丢失、容量大、价格实惠等优势，成为了最重要的存储设备之一。 虽然最初 &amp;lsquo;磁盘&amp;rsquo; 狭义上的概念专指使用磁性材料的存储设备，但在今天，这个词已经泛指所有的持久化存储设备。让我们一起来探</description>
    </item>
    
    <item>
      <title>容器网络可视化：Weave Scope</title>
      <link>https://huweicai.com/weave-scope/</link>
      <pubDate>Wed, 27 Apr 2022 23:42:00 +0800</pubDate>
      
      <guid>https://huweicai.com/weave-scope/</guid>
      <description>Scope 简介 scope 是 weavework 开源的一款容器集群网络可视化监控方案，可以提供整个集群的实时网络拓扑，能具体到容器内进程这一粒度，同时还能提供对容器进行简单的详情查看、销毁、远程登录等管理功能。 功能 Overview 下图是 scope 的管理后台，打开可以看到图中有很多个六边形，代表一个个容器，而容器之间的连线则代表它们之间当前存在网络连接，鼠标悬浮到线条之上还能看到连接发起的方向，这样我们就能直观地观察到整个集群的网络流量拓扑了，哪几个服务之</description>
    </item>
    
    <item>
      <title>Linux 内核轻量级调试小技巧</title>
      <link>https://huweicai.com/kernel-debug-tips/</link>
      <pubDate>Sun, 13 Mar 2022 00:00:00 +0800</pubDate>
      
      <guid>https://huweicai.com/kernel-debug-tips/</guid>
      <description>Kernel 内核承担了核心的操作系统工作，是当今软件生态的基石，因此了解内核是如何工作的能极大的帮助我们更好地构建用户态系统。 学习软件源代码最好的方式就是边看边 DEBUG，软件 = 代码 + 数据，看代码的同时了解其运行时数据能让我们更好的理解整体逻辑。 但内核毕竟不是普通的软件系统，并不是简单的在 IDE 里面一点就能断点调试的，虽然也可以通过 kgdb + qemu 实现在 IDE 中的断点调式，不过这样实在是太重了，而且也不能分析正在运行中的线上</description>
    </item>
    
    <item>
      <title>Cilium 容器数据路径</title>
      <link>https://huweicai.com/cilium-container-datapath/</link>
      <pubDate>Sat, 19 Feb 2022 11:00:00 +0800</pubDate>
      
      <guid>https://huweicai.com/cilium-container-datapath/</guid>
      <description>Cilium Cilium 提供了一套基于 eBPF 的容器网络方案，在网络可观测性和隔离策略方面提供了非常多强大的特性。 我们今天主要关注 Cilium 容器数据面路径这个话题，即一个使用 Cilium 做为 CNI 的 Pod 的数据是如何流动的。 这里我们以在 Pod 中向 1.1.1.1:80发起 TCP 连接（nc -v 1.1.1.1 80）的流量为例进行分析，演示的 Cilium 集群使用 veth pair 打通容器和宿主机网络命名空间，同时使用 vxlan 模式来进行跨主机间的 Pod 通信。 这里我们使用 Pod 10.1.128.86 进行演示，其所在 Node IP 为 10.11.224</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/cilium-config/</link>
      <pubDate>Wed, 02 Feb 2022 02:26:00 +0800</pubDate>
      
      <guid>https://huweicai.com/cilium-config/</guid>
      <description>Cilium Cilium 可以说是当下最流行的基于 eBPF 的容器网络方案，基于eBPF 这种内核黑魔法 Cilium 极大地提升了容器网络的可玩性。 Cilium 的参数配置项都是通过 ConfigMapcilium-config配置的 中，，下面我们来一个个的分析一下这个 ConfigMap 里面的参数都有何意义。 本文基于cilium 1.11版本进行分析。 Cilium Config 配置项 意义 kvstore 当使用 KV 数据库存储元信息而不是CRD时，需要设置此项申明具体的KV存储，原来支持 etcd 和 consul 两种选择，不过 1.11 版</description>
    </item>
    
    <item>
      <title>镜像仓库Harbor Pull实现原理</title>
      <link>https://huweicai.com/harbor-pull-principle/</link>
      <pubDate>Sat, 04 Dec 2021 01:19:00 +0800</pubDate>
      
      <guid>https://huweicai.com/harbor-pull-principle/</guid>
      <description>Harbor简介 Harbor 是 VMWare 开源的一个镜像仓库平台，镜像分发和存储逻辑是基于 docker 开源的 registry (后更名为 distribution)实现的，Harbor 主要在其之上扩展了权限管理、镜像扫描、可视化管理后台等平台化功能，和大部分的云原生组件一样，Harbor 也是基于 Go 语言开发的。 Harbor 的系统架构如下图所示，箭头所指方向为数据流向： 一个镜像仓库最核心的功能就是推送和拉取，本文主要讨论 Harbor 镜像拉取具体的实现细节。 在开始之前 我</description>
    </item>
    
    <item>
      <title>CentOS Linux内核升级指南</title>
      <link>https://huweicai.com/upgrade-centos-kernel-version/</link>
      <pubDate>Thu, 24 Jun 2021 21:29:00 +0800</pubDate>
      
      <guid>https://huweicai.com/upgrade-centos-kernel-version/</guid>
      <description>内核 一个 Linux 操作系统，或者叫做 Linux 发行版，比如常见的：CentOS、Debian、Unbuntu 等等，都是由如下五部分构成的，如下图所示，Linux发行版在外层封装了了大量的库、包和工具供用户使用，而底层硬件设备控制相关的能力则仍是由内核提供： 为什么要升级版本 内核也是一个软件， 软件在不断的迭代的过程中会开发很多新的特性，当我们不论是主动还是被动的对内核的新特性有需求而当前版本不支持时，我们就需要升级版</description>
    </item>
    
    <item>
      <title>Fluent Bit介绍</title>
      <link>https://huweicai.com/fluent-bit/</link>
      <pubDate>Wed, 05 May 2021 13:58:00 +0800</pubDate>
      
      <guid>https://huweicai.com/fluent-bit/</guid>
      <description>Fluent Bit Fluent Bit 是一款开源的日志收集组件，资源开销非常小，小到甚至能在嵌入式系统上运行，支持日志解析&amp;amp;过滤&amp;amp;转发，同时作为云原生基金会下的一个子项目，天然支持容器和 k8s 场景。 基本概念 大部分日志收集组件都将系统大致分为输入、缓冲区、输出三大部分，输入部分负责采集日志，采集了之后放在缓冲区，然后输出部分将其再转发到其他系统。 Fluent Bit 将这三大部分细分成了：输入、解析、过滤、缓冲区、路由、输出六个部分：</description>
    </item>
    
    <item>
      <title>手动实现一个Linux容器</title>
      <link>https://huweicai.com/run-linux-container-manual/</link>
      <pubDate>Wed, 14 Apr 2021 16:20:00 +0800</pubDate>
      
      <guid>https://huweicai.com/run-linux-container-manual/</guid>
      <description>容器 容器技术的出现，彻底颠覆了传统的应用交付部署方式，交付的边界不再仅限于代码，而是一整套能 run everywhere 的基础设施，正如容器化领域的集大成者 Docker 的标语所言，这是一个新的时代了： Accelerate how you build, share and run modern applications. 容器本质上就是一个软件包，包含了业务服务及其依赖组件，比如我有一个Java服务，依赖了jdk 14.0.1以及几个外部 jar包，同时我们还依赖发行版的一些特性，需要运行在 debian buster发行版上，那么我们可以把这些通通打</description>
    </item>
    
    <item>
      <title>Kubernetes权限管理概述</title>
      <link>https://huweicai.com/kubernetes-permissions-overview/</link>
      <pubDate>Thu, 18 Mar 2021 21:29:00 +0800</pubDate>
      
      <guid>https://huweicai.com/kubernetes-permissions-overview/</guid>
      <description>对于一个多用户系统而言，权限管理始终是无法忽略的一环，系统规模越大，权限管理就越重要。 以 Git 系统为例，你有一个代码仓库，你是这个仓库的管理员，你们组的同学具有提交代码的权限，你们部门的同学具有只读权限，公司的其他人全部无法查看，这就是一个典型的权限管理场景。 通常在校验权限中分为两个流程，认证和鉴权。 即先判断你是谁：认证，然后再鉴权，判断你有没有这个资源的权限。 毫无疑问，复杂的Kubernetes也具</description>
    </item>
    
    <item>
      <title>Kubectl基本概念&amp;常用命令</title>
      <link>https://huweicai.com/kubectl-concepts-and-commands/</link>
      <pubDate>Thu, 28 Jan 2021 15:01:00 +0800</pubDate>
      
      <guid>https://huweicai.com/kubectl-concepts-and-commands/</guid>
      <description>基本概念 容器化 + Kubernetes 逐渐成为云计算领域计算资源编排调度管理的事实标准，而 kubectl 则提供了一种非常直观和强大的观察操控 k8s集群的方式。 kubectl 是 kubernetes自带的 21 个命令行程序中的一个，其本身的逻辑并不复杂，使用 cobra 来解析命令行参数，读取 .kube/config中存储的认证信息经由 k8s restful api 和集群交互。 kubectl 命令基本格式如下： kubectl [子命令] [资源类型] [资源名称] [选项] 和 docker、git这种复杂的命令行程序一</description>
    </item>
    
    <item>
      <title>如何准确的获取CPU占用率[Linux][Go]</title>
      <link>https://huweicai.com/go-linux-get-cpu-usage/</link>
      <pubDate>Fri, 01 Jan 2021 01:20:00 +0800</pubDate>
      
      <guid>https://huweicai.com/go-linux-get-cpu-usage/</guid>
      <description>如果我们想要获取系统的 CPU 占用率，首先，Go 语言本身是没有帮我们封装这样的 API 的，所以我们只能自己通过其他方式直接向操作系统要，而不同的操作系统“要”的方式都不太一样，我们这里主要基于 Linux 场景来分析。 虽然有现成的 ps 和 top 等工具我们可以读到现成的值，但是这些工具也是基于 proc 文件解析的，对于人眼可读性较友好，但是代码解析时就不那么方便了。 PROCESS 文件系统 在许多 Unix 类系统中，都存在一个 procfs (Process File System) 进程文件系统的概念，用于将内</description>
    </item>
    
    <item>
      <title>VPN是如何工作的</title>
      <link>https://huweicai.com/how-vpn-works/</link>
      <pubDate>Tue, 22 Dec 2020 23:42:00 +0800</pubDate>
      
      <guid>https://huweicai.com/how-vpn-works/</guid>
      <description>VPN 想象一下这两种场景： 你下班家，公司线上一台机器出事故了，这个时候你需要远程到这台机器上来排查并处理问题。 你在其他城市实习，这个时候学校需要选下学期的课了，但是教务网站只对校园网开放。 在这两种场景中，都离不开一种关键的技术：VPN（Virtual Private Network：虚拟局域网）。 VPN提供了一种在公网上安全的加入局域网的方式，可以我们这里就以开源的 OpenConnect VPN 为例，探讨一下 VPN 这种技术是如何安全的将局域网在互</description>
    </item>
    
    <item>
      <title>Minikube安装教程</title>
      <link>https://huweicai.com/minikube-install-tutorial/</link>
      <pubDate>Mon, 14 Dec 2020 16:20:00 +0800</pubDate>
      
      <guid>https://huweicai.com/minikube-install-tutorial/</guid>
      <description>Minikube 是一个迷你版的 k8s，部署极其简单（相较于正常一套完整的k8s系统而言），对于想要学习k8s或者本地开发调试的人而言都是一个非常不错的选择。 注：以下操作均基于 CentOS 7，其他发型版流程大致一样，不过包管理部分会略有差异 安装容器引擎: Docker Kubernetes 是一个容器编排调度系统，但是容器实体还是需要其他系统来创建的，常见的有如：docker、virtual box、kata等，这里我们以最常见的 docker 为例进行安装，如果系统上已</description>
    </item>
    
    <item>
      <title>小米路由器4A百兆版刷OpenWRT</title>
      <link>https://huweicai.com/run-openwrt-on-xiaomi4a100m/</link>
      <pubDate>Tue, 08 Dec 2020 23:47:00 +0800</pubDate>
      
      <guid>https://huweicai.com/run-openwrt-on-xiaomi4a100m/</guid>
      <description>我其实不怎么喜欢写这种教程类的博客，不过苦于刷机过程中资料过少，踩坑过多，特此系统性的捋一下，分享给有缘人，我手上的型号是百兆版的，4A千兆版刷OpenWRT的流程也基本一样，不过需要注意镜像地址什么的自行替换一下。 前提：需要安装 git、python3 以及熟悉基本的终端操作。 OpenWRT 首先我们要对 OpenWRT 有一些最基本的概念，OpenWRT 是一种 Linux 发行版，本质上是一个操作系统，和我们的常见的 Windows、And</description>
    </item>
    
    <item>
      <title>Git实现原理</title>
      <link>https://huweicai.com/git-implementation/</link>
      <pubDate>Wed, 11 Nov 2020 01:43:00 +0800</pubDate>
      
      <guid>https://huweicai.com/git-implementation/</guid>
      <description>基本概念 概述 Git 是一个基于快照的文件版本管理系统，其实现原理是为每个文件计算一个 hash 值然后压缩存储到 .git/objects 目录内，普通文件为 blob 对象，而文件夹也会生成一个对象：tree，这样一个版本的文件就能被根目录串联起来，这个版本的再上层会有一个 commit 对象，commit 对象会有一到多个 parent 指针，指向上一个提交，这样就把一个个版本串联了起来。 commit 的上层还有一个概念叫分支，分支是一个指向 commit 的指针，相当于是对这一系列 commit 的抽象。 这是一</description>
    </item>
    
    <item>
      <title>一个网络数据包的深度解剖</title>
      <link>https://huweicai.com/who-network-capture-analysis/</link>
      <pubDate>Wed, 01 Jul 2020 01:47:00 +0800</pubDate>
      
      <guid>https://huweicai.com/who-network-capture-analysis/</guid>
      <description>众所周知，网络是分层的，国际标准化组织将网络划分了七层，定义于 ISO/IEC 7498-1，也就是我们所熟知的 ISO 七层模型。 自底向上分别是：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。 以我们所熟知的应用层协议，超文本传输协议（HTTP: HyperText Transfer Protocol）为例，它位于这个模型中的最高的一层，应用进程发送 HTTP 请求包发出之后，会一层一层往下叠加头部直到最终变成最底层的物理信号 0 1 0 1 比特流在网线上传输</description>
    </item>
    
    <item>
      <title>Golang 如何排查协程泄漏问题</title>
      <link>https://huweicai.com/troubleshotting-goroutine-leeking/</link>
      <pubDate>Fri, 29 May 2020 19:58:00 +0800</pubDate>
      
      <guid>https://huweicai.com/troubleshotting-goroutine-leeking/</guid>
      <description>背景 周所周知，内存泄漏是一个很严重的问题，会导致系统运行占用资源越来越多，无法释放，直至崩溃。所幸 Go 语言是一门 具有垃圾回收的语言，能大大降低遇到内存泄漏的概率，而我们今天要说的是另外一个棘手的问题：协程泄漏。 协程泄漏：顾名思义就是出现了应该释放而没有被释放的协程，导致系统协程数量一直上升。不像对象回收需要引用计数、三色标记等手段，协程的回收是相当简单的，等待协程将代码从头到尾执行完毕之后这一块儿空</description>
    </item>
    
    <item>
      <title>颜色是如何呈现的</title>
      <link>https://huweicai.com/how-color-present/</link>
      <pubDate>Thu, 09 Apr 2020 01:27:11 +0800</pubDate>
      
      <guid>https://huweicai.com/how-color-present/</guid>
      <description>现实的世界是丰富多彩的，然而我们又是怎么将这种色彩呈现到我们的显示器上的呢？ 人眼如何感知色彩 众所周知，光是一种电磁波，可见光是人眼所能处理的一个电磁波频率区间子集，人眼看到事物是通过光来感知的，颜色的本质就是电磁波的频率，不同频率的光即我们语言中所定义的不同种类的颜色。本质上我们的眼睛和雷达并没有任何区别，只是大脑的解码渲染能力强一点罢了。 人的眼睛中有视锥细胞和视杆细胞，视杆细胞负责感受光的强度，</description>
    </item>
    
    <item>
      <title>找出使用最频繁的Shell命令</title>
      <link>https://huweicai.com/most-frequently-command/</link>
      <pubDate>Fri, 20 Mar 2020 19:58:00 +0800</pubDate>
      
      <guid>https://huweicai.com/most-frequently-command/</guid>
      <description>使用最频繁 TOP 10命令： history | awk &#39;{map[$2]++} END { for (a in map )print map[ a ]&amp;quot; &amp;quot; map[ a ]/NR*100 &amp;quot;% &amp;quot; a }&#39;| sort -rn | nl | head 先上成品，然后，我们一步一步分析这行语句都涉及到了命令，它们又是如何拼凑到一块儿完成我们的目的的。 Shell 首先我们需要明确一下 shell 的定义，大家可能经常听到 shell ，shell 脚本这些词，那么 shell 到底是什么呢？ Shell 翻译成中文的意思就是壳，和操作系统内核的核相对应，就是一个基于内核的可操作界面。可操作性界面又分为两种： 图形界面类：Graphi</description>
    </item>
    
    <item>
      <title>进程线程协程的本质区别</title>
      <link>https://huweicai.com/process-thread-goroutine/</link>
      <pubDate>Tue, 17 Mar 2020 01:20:00 +0800</pubDate>
      
      <guid>https://huweicai.com/process-thread-goroutine/</guid>
      <description>现代多任务操作系统通常都会有进程的概念来对任务进行隔离，而为了充分利用多核处理器性能同时又减少进程创建的开销，通常又都会引入更细粒度的调度单元：线程。 我们经常能在教科书上看到对于进程和线程的定义： 进程是操作系统分配资源的最小单位，线程是进行调度的最小单元。 这句话没错，但是只是从职责上给出的定义，而不是基于底层实现出发的。 广义上的线程分为内核态线程和用户态线程两种，内核态线程受操作系统直接调度可以充</description>
    </item>
    
    <item>
      <title>Go语言sync包实现原理分析</title>
      <link>https://huweicai.com/go-package-sync/</link>
      <pubDate>Fri, 10 Jan 2020 00:30:00 +0800</pubDate>
      
      <guid>https://huweicai.com/go-package-sync/</guid>
      <description>Java 语言中有一个 java.util.Concurrent 包提供了大量的并发工，而 Go 语言中也有这样的角色：sync包。 sync.Mutex 锁实现原理 sync.Mutext 是 Go 提供的一种同步原语，用于表达互斥，不过不推荐在业务中使用，根据 Go 的设计思想，应首先考虑通过传递消息（管道）来共享内存，而不是通过共享内存来传递消息 Mutex 结构体如下，只有两个变量，非常简单： type Mutex struct { state int32 // 状态，bitmap sema uint32 // 信号量 } state 字段是一个位图 第 0 位表示是否加锁 第 1 位表示是否已唤醒 第 2 位表示是否为饥饿模</description>
    </item>
    
    <item>
      <title>Go 多路条件语句 Switch 语法详解</title>
      <link>https://huweicai.com/go-switch/</link>
      <pubDate>Thu, 02 Jan 2020 12:09:00 +0800</pubDate>
      
      <guid>https://huweicai.com/go-switch/</guid>
      <description>Switch 是 Go 语言中一种多路条件语句，一般搭配 case 语句使用。 执行逻辑 一个 switch case 条件结构如下所示： switch simpleStatement; condition { case expression1,expression2: statements case expression3: statements default: statements } 和 if 语句类似，switch 语句也可以在条件语句之前执行一段简短的表达式（可以用于很方便的控制变量的作用域），switch case 开始执行时，会先执行这一个表达式（空也算一种），然后计算出条件语句的值，接着按从上到下，从左到右的顺序一个一个的执行 case 语句的条件表达式，如果值相等的话就会进入执行 case 条件</description>
    </item>
    
    <item>
      <title>MySQL建表选项</title>
      <link>https://huweicai.com/mysql-create-options/</link>
      <pubDate>Wed, 13 Nov 2019 00:13:31 +0800</pubDate>
      
      <guid>https://huweicai.com/mysql-create-options/</guid>
      <description>这是一个很常见的 SQL 建表语句： CREATE TABLE `people` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(40) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 SQL 建表语句结构如下： CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name (create_definition,...) [table_options] 我们对照结构可以看到我们的建表语句最后一部分是表选项，而在这里我们指定了两个选项：引擎和字符集，那么总共都有哪些选项可以设置呢？参照MySQL官方文档，我们一起来看看。 AUTO_INCREMENT MySQL 一张表中可以指定一个字段为 auto increment，这样在当这个字段没有指定值时就在当前表最大值的基础上自增，在插入了自增的一</description>
    </item>
    
    <item>
      <title>在线 Markdown 转 PDF 工具评测</title>
      <link>https://huweicai.com/web-markdown-to-pdf-utils/</link>
      <pubDate>Tue, 02 Jul 2019 08:47:11 +0800</pubDate>
      
      <guid>https://huweicai.com/web-markdown-to-pdf-utils/</guid>
      <description>用 Markdown 写了这么久博客，对于这种简约风格还是非常喜欢的，所以在写一些其他文档的时候我也更倾向于这种格式。最近需要写一些 PDF 格式的文档，所以我找了一些在线 Markdown 转 PDF 的网站，不同的网站渲染出来的风格并不一样，我在下面做了一个对比，帮助大家进行选择。 测试数据 # 测试测试 1111111111 / 测试 / 123 Email: test@test.com Test: test Website: https://github.com.cn * * * 123213123 测出测试 真的测试 测试吧 * * * # 二阶段测试 - 真的测试测试 - 真的测试测试/真的测试测试 - 微博：[@Easy](http:</description>
    </item>
    
    <item>
      <title>Java跨平台究竟能跨哪些平台</title>
      <link>https://huweicai.com/java-platforms/</link>
      <pubDate>Mon, 20 May 2019 23:47:00 +0800</pubDate>
      
      <guid>https://huweicai.com/java-platforms/</guid>
      <description>众所周知，Java跨平台的一直被众多Java程序员们津津乐道，“一次编写，到处运行”的设想着实令人心动，虽然会带来一定性能上的问题，但这并不妨碍大家对Java的喜爱，既然都说Java能跨平台，Java 也并不是凭空就能跑在任何机器上，这是不现实的，需要官方针对对应的平台，编译一套对应平台包括 Java 虚拟机（Java Runtime Environment 简称 JRE）在内的 Java 开发工具集（Java Develop Kit，简称 JDK），这样我们编写的 Java 代码才算</description>
    </item>
    
    <item>
      <title>Go知识点杂记</title>
      <link>https://huweicai.com/go-knowledge-points/</link>
      <pubDate>Fri, 05 Apr 2019 23:55:00 +0800</pubDate>
      
      <guid>https://huweicai.com/go-knowledge-points/</guid>
      <description>Go语言的不足 我在使用 Go 语言编程开发时发现的一些问题，记录： 没有泛型，写工具库时很不方便 Go 把错误当成一种函数返回值来处理自有其设计道理，但是一次只能只能处理一个错误则是语法上的不足 编译器不支持尾递归优化，这对于递归代码而言很不友好 strings 库不像 Java 那样直接支持正则 没有三目运算符 官方库提供的锁不支持重入 Go静态链接编译的做法会把二进制包撑的特别大，虽然这带来了较好的可移植性 使用首字母大小写这种隐式的做法来</description>
    </item>
    
    <item>
      <title>Redis FAQ</title>
      <link>https://huweicai.com/redis-faq/</link>
      <pubDate>Fri, 04 Jan 2019 22:43:00 +0800</pubDate>
      
      <guid>https://huweicai.com/redis-faq/</guid>
      <description>Redis 官网 FAQ 翻译以及部分自己生产实践总结的问题 官网FAQ地址 Redos持久化策略：RDB和AOF RDB：数据快照，数据整体快照，吞吐量较大，但单次耗时较长，如果在dump的时候宕机可能会导致数据丢失。 AOF：日志追加，占空间比RDB大，但安全性更好，每秒追加一次日志，丢失数据的可能性会小很多，但是宕机恢复很慢。 而在实际生产环境中，我们通常会将两种持久化策略共同使用，定期进行数据快照，同时保留 AOF 日志，在</description>
    </item>
    
    <item>
      <title>小论计算机Encoding</title>
      <link>https://huweicai.com/computer-encodings/</link>
      <pubDate>Sat, 26 May 2018 12:47:11 +0800</pubDate>
      
      <guid>https://huweicai.com/computer-encodings/</guid>
      <description>乱码问题一直是最让人心烦的一类问题，因为不知从何而来，由何而起，只能一处一处的改编码，运气好了就改成功了，运气不好就继续试，有时候明明把所有能改的地方全改成UTF-8了，却仍然无济于事，着实叫人抓狂。这一切都要从1946年的那个春天说起。 在第一计算机台诞生的时候，那个时候还只有0和1，慢慢的，科学家们厌倦了只有0和1的世界，所以他们就聚在一起开了个会，讨论了讨论，决定按特定的方式将人类语言映射到0</description>
    </item>
    
    <item>
      <title>for{;;}与while(true)的困惑</title>
      <link>https://huweicai.com/confusion-betwwen-forwhiletrue/</link>
      <pubDate>Sun, 04 Mar 2018 21:47:00 +0800</pubDate>
      
      <guid>https://huweicai.com/confusion-betwwen-forwhiletrue/</guid>
      <description>最近在阅读JUC源码的时候，由于多线程并发时情况比较复杂，所以源码中经常出现一些无限循环用于等待确保或是某些目的的完成，通常我一般无限循环都是用while(true)，但是我发现在concurrent包中经常用for(;;)来实现。这让我产生了困惑，难道for(;;)会比while(true)性能更好一些吗？于是我决定自己分别编译比较一下。 我编写了如下的程序： public class Test2 { public void whileTest() { int i = 0; while (true) { i++; } } public</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/chubaofs-csi/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/chubaofs-csi/</guid>
      <description>ChubaoFS CSI 为什么升级就会挂</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/drafts/insomnia/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/drafts/insomnia/</guid>
      <description>INSOMNIA  ​ 失眠是进化遗产与现代文明的碰撞——石器时代的大脑操作系统，运行在21世纪的信息爆炸社会必然产生系统冲突。
 夜深人静，身体疲惫却无法入眠，这是现代人最普遍的困扰之一。我们常觉得失眠是大脑&amp;rdquo;不配合&amp;rdquo;的结果，却不知这恰恰是大脑过度工作的表现。失眠不是休息的缺失，而是另一种形式的脑力活动。理解了大脑在失眠时的运作机制，我们才能真正与它达成和解，找回那份与生俱来却被现代生活剥夺的安眠能力。当你躺在床上数绵羊时，大脑其实正在为你上演一部复杂而精彩的神经科学大戏。
正常入睡：大脑的优雅谢幕 在探讨失眠时大脑的异常活动前，先了解正常情况下大脑是如何进入睡眠状态的，这能帮助我们更好地理解失眠的本质。
睡眠的神经开关 健康的入睡过程是一系列精密协调的神经活动：
 觉醒-睡眠切换：
 下丘脑中的视前区(VLPO)神经元开始活跃，释放抑制性神经递质GABA 这些神经元抑制了保持清醒的系统，包括脑干中的蓝斑和中缝核 腹外侧视前核(VLPO)与促醒系统之间的相互抑制形成了类似&amp;rdquo;翘翘板&amp;rdquo;的开关机制  脑电波的变化：
 清醒时的快速β波(13-30Hz)逐渐转变为放松状态的α波(8-13Hz) 进入浅睡眠后，出现θ波(4-7Hz)和特征性的睡眠纺锤波 最终进入深度睡眠，脑电图显示慢波δ活动(0.5-4Hz)  神经递质转变：
 促进觉醒的神经递质(去甲肾上腺素、乙酰胆碱、组胺)水平下降 促进睡眠的物质(GABA、腺苷、褪黑素)水平上升 这种神经化学平衡的转变使大脑从兴奋状态转向抑制状态   皮层活动的优雅减弱 正常入睡时，大脑皮层活动会出现有序的减弱模式：
 前额叶先行关闭：
 负责高级认知功能的前额叶皮层率先降低活性 这导致逻辑思考和决策能力逐渐减弱，思维变得松散 这种&amp;rdquo;从前到后&amp;rdquo;的关闭顺序是健康睡眠的标志  默认模式网络(Default Mode Network, DMN)活动减少：
 这个负责内部思考和自我反省的网络在入睡时活性显著降低 DMN活动减弱意味着思绪流减少，意识逐渐模糊  感觉皮层的阈值提高：
 视觉、听觉等感觉皮层对外界刺激的反应阈值提高 丘脑(感觉信息的中继站)会阻断大部分感觉信息传入皮层 这使外界干扰逐渐被过滤，为睡眠创造&amp;rdquo;安静环境&amp;rdquo;   身体系统的协同变化 大脑活动变化伴随着身体系统的协同调整：
 体温开始下降(一般下降0.5-1°C) 心率减慢，血压降低 肌肉张力减轻，呼吸变得更加规律 内分泌系统调整，生长激素释放准备增加  正常入睡是一场精心编排的神经交响曲，从警觉系统的关闭到皮层活动的减弱，再到身体节律的调整，一切都按照特定顺序和节奏进行。失眠，则是这场交响曲中某些乐器不合时宜地独奏，或某些部分的节奏被打乱。
明明困却睡不着：失眠时的大脑悖论 了解了正常入睡的过程，现在让我们看看失眠者的大脑发生了什么。
昨晚，我经历了一次&amp;rdquo;典型失眠&amp;rdquo;：疲惫地躺下，眼皮沉重，却在床上辗转反侧到凌晨三点。明明身体每个细胞都在叫嚣着要休息，大脑却像打了鸡血一样亢奋。
这种矛盾的体验并非个例。据统计，约三分之一的成年人经常遭遇失眠困扰，而临床失眠症的患病率已达到10%左右。失眠正在成为现代社会的流行病。
但这种现象有个奇怪之处：我们的祖先几乎不知道&amp;rdquo;失眠&amp;rdquo;为何物，原始部落的人们也很少报告睡眠问题。这说明失眠很可能不是人类的自然状态，而是现代生活方式的副产品。
人类进化了数十万年的睡眠机制，却在短短几代人的时间里被现代文明打乱。这不是个体的失败，而是我们的神经系统尚未跟上文明奔跑的脚步。
失眠时的大脑：一场神经元的派对 当你辗转反侧时，大脑究竟在忙些什么？神经科学家通过脑电图、功能性核磁共振等技术，揭示了失眠大脑的秘密活动。
警觉系统的过度活跃 正常入睡时，由脑干中的网状激活系统(Reticular Activating System, RAS)控制的警觉系统会逐渐降低活性，让大脑进入休息状态。但在失眠者身上，这个系统仍保持着不必要的高度警觉：
 蓝斑(Locus Coeruleus)：这个产生去甲肾上腺素的核团在失眠者睡前仍保持高活性 背侧缝核(Dorsal Raphe Nucleus)：负责产生5-羟色胺，在失眠时调节异常 下丘脑的泌素神经元：本应促进睡眠的系统被其他信号所抑制  简单来说，你的大脑仍处于&amp;rdquo;警戒模式&amp;rdquo;，就像一个保安在空无一人的大楼里坚持巡逻，消耗能量却没有实际需求。
默认模式网络：止不住的思绪列车 失眠时特别活跃的还有大脑的&amp;rdquo;默认模式网络&amp;rdquo;——负责处理自我相关信息、回忆过去和规划未来的神经网络。它包括：
 内侧前额叶皮层 后扣带回 楔前叶 顶下小叶  正常入睡时，这个网络的活性应当下降，但失眠者的默认模式网络却异常活跃。这就解释了为什么你躺在床上时，脑子里会不自主地回顾今天的尴尬瞬间，或者开始规划下周的工作安排。
我们的思绪就像一列无人驾驶的火车，在夜晚的轨道上不停奔跑。明知道目的地是虚无，却无法找到刹车。
边缘系统：情绪的夜间余震 失眠者的大脑中，情绪处理系统也不安分：
 杏仁核(Amygdala)：负责处理恐惧和焦虑的脑区在失眠者中常常过度活跃 前扣带回(Anterior Cingulate Cortex, ACC)：情绪调节和注意力控制的关键区域也显示出异常活动模式  这解释了为什么失眠常伴随着焦虑情绪：大脑的情绪中枢在安静的夜晚反而开始&amp;rdquo;大声说话&amp;rdquo;。
一项研究发现，失眠者的杏仁核对中性面孔图片的反应比正常睡眠者更强烈，这表明他们的大脑倾向于将中性信息解读为威胁。
前额叶皮层：无法下班的执行官 负责高级认知功能的前额叶皮层在失眠者中难以&amp;rdquo;下班&amp;rdquo;：
 背外侧前额叶皮层(Dorsolateral Prefrontal Cortex, DLPFC)：负责逻辑思考和问题解决的区域继续活跃 眶额皮层(Orbitofrontal Cortex)：参与决策过程的区域保持工作状态  这就像公司的CEO在深夜仍在办公室踱步，思考着本可以等到明天再处理的问题。
失眠的本质，是大脑各系统之间的不协调：一部分准备休息，另一部分却拒绝关机。这种内部冲突，就是我们躺在床上感到的那种撕扯感。
为什么会失眠：现代生活中的神经触发器 既然失眠是大脑运作的异常模式，那么是什么触发了这种异常？
光照节律的混乱 人类进化出了对光照极为敏感的生物钟系统：
 视交叉上核(Suprachiasmatic Nucleus, SCN)：下丘脑中的主生物钟，依靠光信号来调节昼夜节律 松果体根据光照信息调节褪黑素的分泌  但现代生活中，我们被各种人工光源包围：
 夜间室内灯光推迟了褪黑素的分泌 电子屏幕（特别是富含蓝光的屏幕）直接抑制了褪黑素的产生 不规律的作息进一步混淆了大脑的时间感知  我们的祖先随日落而眠，随日出而起。现代人却通过电灯欺骗大脑，让它误以为太阳永不落山。
压力与警觉系统 现代生活中的压力因素直接激活了大脑的警觉系统：
 工作压力和生活焦虑提高了皮质醇水平 不断增长的社会期望创造了持续的压力状态 信息过载让大脑难以完全放松  研究发现，一个重要的工作会议可以使失眠风险提高70%，而财务压力则可能让失眠概率翻倍。
思维模式的恶性循环 失眠者往往陷入关于睡眠的负面思维循环：
 担心睡不着 这种担忧产生焦虑 焦虑激活警觉系统 更难入睡 加剧对睡不着的担忧  一项追踪研究显示，那些&amp;rdquo;担心睡不好&amp;rdquo;的人比那些&amp;rdquo;不担心睡眠问题&amp;rdquo;的人更容易发展出真正的失眠症，即使两组人初始的睡眠质量相似。
担心失眠本身就是失眠的催化剂，这是一个完美的自我实现预言。在床上越是努力尝试入睡，睡意反而越会远离我们。
失眠的神经科学后果：为什么一晚糟糕的睡眠影响深远 失眠不仅仅是难以入睡那么简单，它对大脑的影响是多方面的：
前额叶功能下降 失眠后，前额叶皮层的功能受到明显抑制：
 工作记忆容量减少约40% 决策质量下降，风险评估能力减弱 情绪调节能力受损，容易产生负面情绪  这就是为什么失眠后我们会感到&amp;rdquo;脑子不清醒&amp;rdquo;、&amp;rdquo;反应变慢&amp;rdquo;：大脑的指挥中心正在低效运转。
杏仁核敏感性增加 睡眠不足会增加杏仁核对负面刺激的反应强度：
 对压力源的情绪反应增强约60% 更容易感到焦虑和易怒 对积极刺激的反应却减弱  有项有趣的研究发现，失眠一晚后，人们对同一个笑话的评价会降低20%，这表明失眠降低了我们感受积极情绪的能力。
海马体记忆编码受损 失眠对负责记忆形成的海马体(Hippocampus)影响尤为显著：
 新记忆的形成效率降低 记忆巩固过程受到干扰 长期睡眠问题与海马体体积减小相关  睡眠不是大脑的休息时间，而是记忆整合的关键期。失眠就像是打断了图书管理员的工作，让前一天获取的知识无法被妥善归档。
清除系统效率降低 睡眠时，大脑的胶质淋巴系统(Glymphatic System)（相当于大脑的&amp;rdquo;下水道&amp;rdquo;）会清除代谢废物：
 睡眠期间，脑脊液流动增加约60% β-淀粉样蛋白等有害物质被清除 失眠会显著降低这一清除效率  长期失眠与阿尔茨海默病等神经退行性疾病的风险增加之间的关联，很可能与这一清除功能的减弱有关。
大脑的自我修复：失眠后的补偿机制 面对失眠，大脑并非毫无应对之策，它有着自己的应急机制：
微睡眠：大脑的偷懒时刻 当你严重缺乏睡眠时，大脑会启动&amp;rdquo;微睡眠&amp;rdquo;(Microsleep)状态：
 持续数秒的局部脑区进入睡眠状态 其他区域继续保持清醒 这种状态下人体仍可维持基本功能  你可能体验过开车或听讲座时突然&amp;rdquo;神游&amp;rdquo;几秒，这可能就是微睡眠的表现。这是大脑在尝试&amp;rdquo;偷&amp;rdquo;一点睡眠，但也带来了注意力和反应能力的显著下降。</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/drafts/%E7%BD%91%E5%8D%A1%E6%98%AF%E5%A6%82%E4%BD%95%E8%BF%90%E4%BD%9C%E7%9A%84/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/drafts/%E7%BD%91%E5%8D%A1%E6%98%AF%E5%A6%82%E4%BD%95%E8%BF%90%E4%BD%9C%E7%9A%84/</guid>
      <description></description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/personal/go%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/personal/go%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B/</guid>
      <description>Go内存示意图 page 内存页面的最小单元，大小为：_PageShift = 13;_PageSize = 1 &amp;lt;&amp;lt; _PageShift = 8KB
mheap 是一个全局唯一的对象，代表整个堆，当堆空间不够时，会通过 mmap 系统调用申请一块大小为 64MB 的内存，封装为一个 arena 进行管理。
mheap 中 arenas 数组最多可以管理：4194304 个 arena，每个 arena 64MB，所以 mheap 总共可以管理 256TB 的内存。
type mheap struct { allspans []*mspan // all spans out there arenas [1]*[4194304]*heapArena central [134]struct { // 134 = 57 * 2，有 57 种大小类型的内存 mcentral mcentral } }  arena 每个 arena 64 MB
// pagesPerArena = 8192 = 8 * 1024 // heapArenaBitmapBytes = 2097152 = 2 * 1024 * 1024 type heapArena struct { // bitmap stores the pointer/scalar bitmap for the words in // this arena. See mbitmap.go for a description. Use the // heapBits type to access this. bitmap [heapArenaBitmapBytes]byte spans [pagesPerArena]*mspan // 页到 mspan 的映射 pageInUse [pagesPerArena / 8]uint8 // bitmap 标记哪些页在使用中 }  mspan Go 内存分配的最基本单元，从 8KB 到 32KB 分为 67 个不同的类别
type mspan struct { next *mspan // 用于在 mheap 上构建 mspan 链表 prev *mspan // 用于在 mheap 上构建 mspan 链表 startAddr uintptr // 内存开始地址 npages uintptr // page 的数量 }  mcentral 相同大小的 mspan 会归类到一个 mcentral 中，内存不够时从 mheap 申请
type mcentral struct { nonempty mSpanList // 使用中 empty mSpanList // 空闲列表 }  mcache P 私有的小对象内存管理者，从 mcentral 申请新内存。
小对象（&amp;lt; 32KB）会在 mcache 上申请，不用加锁，大对象则在 mheap 上直接分配。</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/personal/%E5%8D%95%E6%9C%BA%E5%AE%B9%E5%99%A8%E7%BD%91%E7%BB%9C%E6%A8%A1%E5%9E%8B/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/personal/%E5%8D%95%E6%9C%BA%E5%AE%B9%E5%99%A8%E7%BD%91%E7%BB%9C%E6%A8%A1%E5%9E%8B/</guid>
      <description> ``` slug: &amp;ldquo;stand-alone-network-model&amp;ldquo; tags: [&amp;ldquo;操作系统&amp;rdquo;,&amp;ldquo;网络&amp;rdquo;,&amp;ldquo;Linux&amp;rdquo;,&amp;ldquo;docker&amp;rdquo;,&amp;ldquo;容器&amp;rdquo;] date: 2021-06-20T01:20:00+08:00 toc: true title: 经典单机容器网络模型-Docker
参考文档  https://docs.docker.com/network/bridge/ https://docs.docker.com/network/iptables/  </description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/favoriteblogs/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/favoriteblogs/</guid>
      <description>https://deepu.tech/
https://draveness.me/</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/fluentbitoutput/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/fluentbitoutput/</guid>
      <description>The stdout filter plugin allows printing to the standard output the data flowed through the filter plugin, which can be very useful while debugging.
The plugin has no configuration parameters, is very simple to use.
Command Line $ bin/fluent-bit -i cpu -F stdout -m &#39;*&#39; -o null  We have specified to gather CPU usage metrics and print them out in a human-readable way when they flow through the stdout plugin, setting -m &#39;*&#39;to print all the metrics.
Fluent Bit v1.8.0 * Copyright (C) 2019-2021 The Fluent Bit Authors * Copyright (C) 2015-2018 Treasure Data * Fluent Bit is a CNCF sub-project under the umbrella of Fluentd * https://fluentbit.io [2021/06/04 14:53:59] [ info] [engine] started (pid=3236719) [2021/06/04 14:53:59] [ info] [storage] version=1.1.1, initializing... [2021/06/04 14:53:59] [ info] [storage] in-memory [2021/06/04 14:53:59] [ info] [storage] normal synchronization mode, checksum disabled, max_chunks_up=128 [2021/06/04 14:53:59] [ info] [sp] stream processor started [0] cpu.0: [1622789640.379532062, {&amp;quot;cpu_p&amp;quot;=&amp;gt;9.000000, &amp;quot;user_p&amp;quot;=&amp;gt;6.500000, &amp;quot;system_p&amp;quot;=&amp;gt;2.500000, &amp;quot;cpu0.p_cpu&amp;quot;=&amp;gt;8.000000, &amp;quot;cpu0.p_user&amp;quot;=&amp;gt;6.000000, &amp;quot;cpu0.p_system&amp;quot;=&amp;gt;2.000000, &amp;quot;cpu1.p_cpu&amp;quot;=&amp;gt;9.000000, &amp;quot;cpu1.p_user&amp;quot;=&amp;gt;6.000000, &amp;quot;cpu1.p_system&amp;quot;=&amp;gt;3.000000}] [0] cpu.0: [1622789641.379529426, {&amp;quot;cpu_p&amp;quot;=&amp;gt;22.500000, &amp;quot;user_p&amp;quot;=&amp;gt;18.000000, &amp;quot;system_p&amp;quot;=&amp;gt;4.500000, &amp;quot;cpu0.p_cpu&amp;quot;=&amp;gt;34.000000, &amp;quot;cpu0.p_user&amp;quot;=&amp;gt;30.000000, &amp;quot;cpu0.p_system&amp;quot;=&amp;gt;4.000000, &amp;quot;cpu1.p_cpu&amp;quot;=&amp;gt;11.000000, &amp;quot;cpu1.p_user&amp;quot;=&amp;gt;6.000000, &amp;quot;cpu1.p_system&amp;quot;=&amp;gt;5.000000}] [0] cpu.0: [1622789642.379544020, {&amp;quot;cpu_p&amp;quot;=&amp;gt;26.500000, &amp;quot;user_p&amp;quot;=&amp;gt;16.000000, &amp;quot;system_p&amp;quot;=&amp;gt;10.500000, &amp;quot;cpu0.p_cpu&amp;quot;=&amp;gt;30.000000, &amp;quot;cpu0.p_user&amp;quot;=&amp;gt;24.000000, &amp;quot;cpu0.p_system&amp;quot;=&amp;gt;6.000000, &amp;quot;cpu1.p_cpu&amp;quot;=&amp;gt;22.000000, &amp;quot;cpu1.p_user&amp;quot;=&amp;gt;8.000000, &amp;quot;cpu1.p_system&amp;quot;=&amp;gt;14.000000}] [0] cpu.0: [1622789643.379507371, {&amp;quot;cpu_p&amp;quot;=&amp;gt;39.500000, &amp;quot;user_p&amp;quot;=&amp;gt;34.500000, &amp;quot;system_p&amp;quot;=&amp;gt;5.000000, &amp;quot;cpu0.p_cpu&amp;quot;=&amp;gt;52.000000, &amp;quot;cpu0.p_user&amp;quot;=&amp;gt;48.000000, &amp;quot;cpu0.p_system&amp;quot;=&amp;gt;4.000000, &amp;quot;cpu1.p_cpu&amp;quot;=&amp;gt;28.000000, &amp;quot;cpu1.p_user&amp;quot;=&amp;gt;21.000000, &amp;quot;cpu1.p_system&amp;quot;=&amp;gt;7.000000}] ^C[2021/06/04 14:54:04] [engine] caught signal (SIGINT) [2021/06/04 14:54:04] [ info] [input] pausing cpu.</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/javascript/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/javascript/</guid>
      <description></description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/k8s%E5%85%A5%E9%97%A8/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/k8s%E5%85%A5%E9%97%A8/</guid>
      <description>基本概念
Node 一个节点，一台物理机器
kubelet Node上的一个管理程序，一台物理机一个
POD 一个 pod 就是一个运行服务的基本节点，k8s中的最小单元，对应一组（一个或者多个）容器，共享网络、进程信息、文件等上下文。
Service Service 代表一种服务，可能分配在很多台机器上，由 k8s 统一管理，注册在 etcd 上，k8s 可以生成提供一个统一的一个 URL 对外提供服务。
Kubectl 一个通过 HTTP API 和 k8s 服务端交互的客户端
Master k8s集群的核心节点，包含一些调度、管理、配置服务
 API Server Scheduler Control-Manager ETCD  Docker-Compose https://github.com/docker/compose
用于在单机系统上编排 docker 镜像
Swarm docker 官方提出的一个 k8s 竞品，可以将多个镜像聚合成一个服务的概念运行。
jaeger，zipkin 一个分布式链路追踪应用</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/linux%E6%A8%A1%E5%9D%97%E7%AE%A1%E7%90%86%E6%9C%BA%E5%88%B6/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/linux%E6%A8%A1%E5%9D%97%E7%AE%A1%E7%90%86%E6%9C%BA%E5%88%B6/</guid>
      <description></description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/untitled/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/untitled/</guid>
      <description></description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/%E5%A6%82%E4%BD%95%E8%AE%BE%E8%AE%A1%E4%B8%80%E4%B8%AA%E7%A7%92%E6%9D%80%E7%B3%BB%E7%BB%9F/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/%E5%A6%82%E4%BD%95%E8%AE%BE%E8%AE%A1%E4%B8%80%E4%B8%AA%E7%A7%92%E6%9D%80%E7%B3%BB%E7%BB%9F/</guid>
      <description>第一代 静态资源上CDN。
前端部分用户点击一次就置灰，提示&amp;rdquo;你点击的太频繁了哦&amp;rdquo;，然后对域名发起请求，DNS解析后打到后端实例上。
后端部分，需要选择一门性能较好的语言，解释型语言比如：Python、PHP肯定就先排除了，考虑到可维护性肯定要选一门使用人数多一点的编译型语言：Go、C++、Java，综合可维护性、开发效率、并发友好度来说，Golang 会是一个比较不错的选择，框架部分可以使用Gin+Gorm。
服务部署的话直接部署到公网机器上即可，数据存储挂一个 MySQL 即可。
MySQL 上个好点的 SSD，RAID 冗余高可用。
会在 5K QPS 的时候，MySQL 开始比较吃力。
第二代: 优化MySQL 在第一代基础上读写分离：Master-Replica-ReadonlySlave，先查读库，还有的话再去查主库加事务下单
MySQL 使用 5.7 的 MySQL-Group-Replication 架构，第二代是单主结构，MGR 实现了 Paxos 分布式共识算法，集群中多个节点可以写入。
第三代：引入Redis 使用 Redis 来作为中心式存储来保存订单数量的数据，单实例可以到 5W QPS，是单机 MySQL 的十倍。
Redis master 读写分离架构一个集群，和 MySQL 一样：Master-Replica-ReadonlySlave，多机共同提供服务，可支撑的 QPS 再上一个量级，到 50W QPS不成问题。
第四代：服务内部限流 很多时候，用户可以接受点了秒杀之后过会儿才返回结果，而秒杀的绝大部分流量都会集中在头一秒钟，可以在服务内部实现一个FIFO限流桶，事先通过压测测量出 Redis 安全水位，每台实例限流 Redis 总安全水位/ 服务实例数量，等待超过 4 秒钟的返回超时错误。
这样一定程度能削减峰值流量平摊到相对低峰期内。
然后当发现库存变零了之后，就在内存中缓存一个值一秒钟，代表已经没有库存了直接返回失败就好，一秒钟过期是因为之后可能有人又释放之前锁定的库存，不过这种设计不是特别的强公平，需要跟业务沟通好需求。
这样一轮下来，整体秒杀服务扛个 200W QPS 不成问题。
可以再加一个终极降级的开关，当系统开始大量报错摇摇欲坠时，比例丢弃一些用户请求。
第五代：Keepalived+LVS+Nginx流量接入高可用 目前我们的系统设计仍然是Go程序直接挂在公网机器上对外提供服务，这样会有很大的问题：
 DNS调节反应慢，服务宕机无法迅速摘掉 浪费公网IP资源 流量分布不一定均匀  所以我们可以考虑引入七层负载均衡层：Nginx、Caddy、HAProxy等，
Nginx 使用人数最插件丰富多资料最全所以我们优先考虑使用这个，可以使用默认的轮询或者fair算法来实现负载均衡。
单台 Nginx 如果挂了也还是会有问题，我们可以使用 Keepalived IP漂移技术来保证在 DNS 上注册的单个 IP 的高可用。
Nginx 机器多了之后公网 IP 资源和虚IP资源仍然是一笔不小的开销，这个时候我们可以再引入一层四层负载均衡，只解到四层的包，工作更加简单因此可以承担更大的流量，我们只需要部署少量几个公网虚IP即可承担这个系统的流量。
具体选型可以使用 LVS，或者爱奇艺的 DPVS 也是一个不错的选择，不过如果不差钱的话，硬负载均衡器肯定是性能上的首选。
外层可以再挂一层CDN动态加速，构建多机房共同提供服务。
第六代：限流反作弊，去除无用流量 Nginx 可以实现 uid 或者 ip 限流，但是这很明显不是中心式的。
可以收集 Nginx 日志，从中解析出客户端 IP，UID 等信息统一扔到 Kafka 中交由反作弊服务进行实时计算，最终维护一个黑名单的 redis map，服务每次都先去访问一下这个 redis map 如果是异常流量就直接拒绝。
CDN动态加速+多机房分流
IP漂移：一台机器挂了之后，依赖DNS去恢复是非常困难的，可以通过 ARP 实现 IP 漂移来实现机器高可用。Keepalived
四层负载均衡：工作比七层更简单，性能消耗小，有利于收敛所有的TCP/UDP流量
七层负载均衡：Nginx、Caddy、HAProxy、Apache 负载均衡
服务逻辑：Gin</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/%E7%AE%97%E6%B3%95%E5%BF%83%E5%BE%97/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/%E7%AE%97%E6%B3%95%E5%BF%83%E5%BE%97/</guid>
      <description> 链表类 数组类 二叉树类 </description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80%E5%AF%B9%E6%AF%94/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80%E5%AF%B9%E6%AF%94/</guid>
      <description>    Java Golang Node JS     包管理 maven module npm   依赖描述文件 pom.xml go.mod package.json          </description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/temp/%E8%BF%91%E8%A7%86%E7%9A%84%E6%9C%AC%E8%B4%A8/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/temp/%E8%BF%91%E8%A7%86%E7%9A%84%E6%9C%AC%E8%B4%A8/</guid>
      <description>https://www.ixueshu.com/download/c2ce2a60dbe1de5d6a92cef1e8e10afb318947a18e7f9386.html
部分学者有一个很有意思的观点，近视有可能是人类现代社会化的正常产物，我们不应该视其为洪水猛兽，而应正常对待，只有一个人戴眼镜校正后的视力是正常的，那么他就是一个健康的正常人。
[]()</description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/untitled/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/untitled/</guid>
      <description></description>
    </item>
    
    <item>
      <title></title>
      <link>https://huweicai.com/%E4%B8%BA%E4%BB%80%E4%B9%88%E6%97%B6%E9%97%B4%E6%9C%89%E6%97%B6%E5%BF%AB%E6%9C%89%E6%97%B6%E6%85%A2/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://huweicai.com/%E4%B8%BA%E4%BB%80%E4%B9%88%E6%97%B6%E9%97%B4%E6%9C%89%E6%97%B6%E5%BF%AB%E6%9C%89%E6%97%B6%E6%85%A2/</guid>
      <description>为什么时间有时快有时慢   注意力资源分配：大脑对时间的感知受注意力调控，当专注处理复杂任务时，认知资源集中于当前活动，时间感知神经元（如基底神经节、前额叶皮层）活动减少，主观上感觉时间变快；反之，无聊时注意力分散，时间感知被强化，感觉时间变慢。 记忆编码密度：高刺激事件触发海马体强化记忆编码，事后回忆信息密度高，主观上认为时间“更长”；而重复性活动记忆痕迹稀疏，感觉时间“更短”。 多巴胺调控：多巴胺水平影响时间感知，愉悦状态下多巴胺释放增多（如伏隔核激活），会加速内部计时器（如纹状体-皮层环路），使主观时间变快；而焦虑时多巴胺降低，计时误差增大，感觉时间拖沓。 时间本质是主体对变化的度量，其快慢并非物理时间的伸缩，而是意识在经验密度与意义投射中建构的感知幻象——当存在与虚无的张力失衡时，时间便沦为心灵丈量自由的尺度。   时间，这个看不见摸不着的维度，却是我们感知世界最基础的框架。童年的夏天漫长如永恒，而年岁渐长后，岁月却如同从指缝中滑落的沙粒。这不是时间本身在变化，而是我们的大脑在以不同方式感知它。所谓时间的快慢，不过是大脑对经历密度的一种主观体验。理解了这一点，我们才能真正掌握自己的时间感，让生命在有限的刻度里绽放出最丰富的色彩。
时间感知：人人都有的错觉 春节的时候，我陪父母看完一部两小时的电影（今年很火的那部）。电影很精彩，但我妈在散场时却感叹：&amp;rdquo;这电影也太长了吧，感觉看了一整天。&amp;rdquo;而我却觉得时间过得飞快，仿佛刚坐下没多久就结束了。
同样的两小时，为什么在不同人眼中长短各异？为什么假期总是一眨眼就过去，而工作日的下午却仿佛被时间遗忘？
这不是错觉，而是大脑的时间感知机制在起作用。
与我们的直觉相反，时间并不是匀速流动的——至少在我们的主观感受中是这样。心理学家早就发现，人类的时间感知具有高度的主观性和可塑性。当我们全神贯注于一件事情时，三小时可能感觉只有一小时那么长；而当我们焦急地等待某个事件发生时，三分钟可能会被拉长成三十分钟的体验。
时间不会加速或减速，改变的只是我们的感知。理解这种感知的机制，就等于掌握了部分驾驭时间的能力。
大脑如何感知时间？ 与视觉、听觉不同，我们的大脑中并没有专门的&amp;rdquo;时间感受器&amp;rdquo;。那么，大脑是如何感知时间的呢？ 时钟神经元：内部的计时器
神经科学家发现，我们的大脑中存在着一种被称为&amp;rdquo;时钟神经元&amp;rdquo;的细胞，主要分布在大脑的基底神经节、小脑和前额叶皮层。这些神经元会以一种相对规律的方式放电，像心脏的跳动一样，为大脑提供基础的节律感。
这些神经元放电的频率会受到多种因素的影响：
 多巴胺等神经递质的水平
 身体的核心温度 注意力的分配状态 情绪的变化  举个简单的例子，当我们处于兴奋状态时，大脑中的多巴胺水平上升，时钟神经元的放电频率加快，这会让我们感觉时间过得更快。相反，在焦虑或无聊时，时钟神经元的放电频率可能减慢，时间体验被拉长。
这就解释了为什么做喜欢的事情时&amp;rdquo;一小时恍如一分钟&amp;rdquo;，而做枯燥任务时&amp;rdquo;一分钟长如一小时&amp;rdquo;的感受。
记忆密度：时间感知的另一维度 除了实时的时间感知外，我们对过去时间长短的判断更多取决于记忆的密度。记忆越丰富、越独特的时间段，在回忆时会被感知为更长；而重复、单调的时间段则会在记忆中被压缩。
这就是为什么孩童时代的记忆显得格外漫长——对孩子来说，几乎每一天都充满了新鲜经历。而成年后，日复一日的重复生活让时间在记忆中失去了厚度。
生活不是由我们呼吸的次数计算，而是由那些让我们屏息的时刻组成。在记忆的天平上，新鲜体验的重量远超日常重复。
时间感知的主观性 既然时间感知如此主观，那么究竟哪些因素会影响我们对时间的体验呢？
注意力分配 心理学家提出了&amp;rdquo;注意力门控&amp;rdquo;理论：当我们的注意力被外部任务占据时，分配给时间流逝的注意力就会减少，导致我们低估了时间的长度。
想想看，当你打游戏或看一部精彩电影时，你几乎不会注意时间的流逝；而当你排队等候或等待面试结果时，你可能会不断查看手表，这时你会更加清晰地感受到每一分每一秒。
有项有趣的实验：研究者让受试者完成两项任务，一项需要高度专注，另一项较为简单。尽管两项任务持续时间相同，但受试者普遍认为高专注任务的时间更短。
注意力就像聚光灯，它照到哪里，哪里就会被放大感知；而阴影处的事物，包括时间本身，则会在感知中缩小。
情绪状态 我们的情绪状态也会显著影响时间感知：
积极情绪（如快乐、兴奋）通常会让人感觉时间过得更快 消极情绪（如悲伤、焦虑）则往往让时间感觉被拉长 惊吓或危险状态会激活&amp;quot;时间膨胀效应&amp;quot;，让瞬间被感知为更长  曾有研究让参与者从高处自由落体，并在下落过程中观看一个数字计时器。结果发现，参与者普遍高估了下落的时间，感觉时间被&amp;rdquo;拉长&amp;rdquo;了。这是因为在危险情况下，大脑会加速处理信息，创造一种&amp;rdquo;慢动作&amp;rdquo;的感知，让人有更多时间做出反应。
这就是为什么车祸等危险事件中，当事人常常描述&amp;rdquo;时间仿佛静止了&amp;rdquo;或&amp;rdquo;一切都变成了慢动作&amp;rdquo;。
在危险面前，大脑会自动开启&amp;rdquo;高速摄影模式&amp;rdquo;，让瞬间的信息被细致捕捉，这是为生存而设计的本能反应。
年龄因素 &amp;ldquo;年纪越大，时间过得越快&amp;rdquo;几乎是人人都有的体验。这种现象有着深刻的神经科学和心理学基础：
相对论效应：对一个5岁的孩子来说，1年相当于他生命的20%；而对一个50岁的人来说，1年只是生命的2%。从比例上看，同样的时间对年长者来说自然显得更短。 新奇度减少：随着年龄增长，真正新鲜的体验越来越少。第一次恋爱、第一次独自旅行、第一次当父母——这些里程碑式的体验在生命中是有限的。缺乏新鲜感使得记忆密度降低，时间在回忆中被压缩。 认知处理速度：年龄增长伴随着神经传导速度的微妙变化，可能影响内部时钟的运行速率。  有一位90多岁的老人曾对我说：&amp;rdquo;年轻时，一年好像有365天；现在的一年，好像只有几个星期那么长。&amp;rdquo;这句朴实的话，道出了时间感知随年龄变化的本质。
药物和疾病 某些药物和神经系统疾病会显著影响时间感知：
咖啡因等兴奋剂可能加速主观时间流逝 酒精和大麻等物质则可能导致时间感知减慢 帕金森病患者（多巴胺水平低下）通常会高估时间间隔 抑郁症患者常常感觉时间过得极其缓慢  精神分裂症患者可能会经历严重的时间感知障碍，这与他们前额叶皮层和基底神经节的多巴胺调节异常有关。
时间感知的异常常常是大脑健康状况的一面镜子，反映出神经递质平衡的细微变化。 深入大脑：时间感知的神经机制
现在，让我们更深入地了解大脑如何感知和处理时间信息。
多重时间系统 根据现有神经科学研究理论，我们的大脑至少有三套处理不同时间尺度的系统：
 毫秒级系统：主要由小脑控制，用于协调精细动作、语言发音等需要精确计时的活动 秒到分钟级系统：由基底神经节和前额叶构成的网络负责，这是我们最常感知的时间尺度 昼夜节律系统：由下丘脑的视交叉上核控制，调节睡眠-觉醒周期等长时间节律  这些系统通过复杂的神经网络相互连接，共同构成了我们对时间的完整感知。
前额叶皮层：时间感知的总指挥 前额叶皮层，特别是其右侧部分，在时间感知中扮演着核心角色。这一区域负责整合来自不同感官的时间信息，形成连贯的时间体验。
有趣的是，当我们全神贯注于某项任务时，前额叶皮层的活动会转向任务处理，减少对时间流逝的监控，这就是为什么专注状态下时间感会加速的神经基础。
研究发现，损伤前额叶皮层的患者常常表现出时间判断能力的严重障碍，他们可能无法正确估计事件持续了多长时间，或者无法按照指定时间完成任务。
多巴胺：时间感知的润滑剂 在所有影响时间感知的神经递质中，多巴胺的作用最为关键。这种与奖励和愉悦感相关的神经递质，也是调节内部时钟速率的重要因子。
多巴胺水平上升：主观时间流逝加快（如兴奋状态） 多巴胺水平下降：主观时间流逝减慢（如疲劳状态）  这就解释了为什么帕金森病患者（多巴胺缺乏）和使用多巴胺阻断剂的人常常感觉时间过得特别慢，而使用增加多巴胺的药物（如可卡因）则会让人感觉时间飞逝。
多巴胺就像是大脑时钟的齿轮油，它的多少决定了时钟运转的快慢，从而影响我们对时间流逝的主观体验。 时间感知的错觉与效应
大脑的时间感知系统虽然精妙，但也充满了各种有趣的&amp;rdquo;bug&amp;rdquo;和特殊效应。理解这些效应不仅满足好奇心，还能帮助我们更好地利用和调整自己的时间体验。
首次效应：新鲜事物的时间膨胀 第一次经历某件事情时，我们通常会感觉时间比实际更长。这是因为大脑在处理新奇信息时需要更多资源，形成更丰富的记忆编码。
举个例子，第一天上班的路程常常感觉特别长，而之后同样的路程就会变得越来越短。这不是因为你走得更快了，而是因为熟悉度增加，大脑处理这段经历时不再那么&amp;rdquo;费力&amp;rdquo;。 等待悖论：期待中的时间拉长
当我们翘首期盼某事发生时，等待的过程常常感觉异常漫长。有趣的是，这种主观时间延长在回忆中却往往被压缩。
比如等待恋人的三分钟可能感觉像三十分钟那么长，但回忆起来可能只是&amp;rdquo;等了一会儿&amp;rdquo;。这种现象被称为&amp;rdquo;时间等待悖论&amp;rdquo;，反映了实时体验和回忆中的时间感知差异。
休假悖论：假期的时间错觉 大多数人都经历过这种现象：假期第一天感觉时间很长，充满可能性；而到了假期结束时，却惊讶于时间过得如此之快。更有趣的是，回顾整个假期时，它可能又会在记忆中&amp;rdquo;膨胀&amp;rdquo;，显得比实际更长。
这种复杂的时间感知变化与注意力分配和记忆形成机制有关：假期中的新鲜体验创造了丰富的记忆，让这段时间在回忆中被感知为更长。
人生就像假期——开始时看似漫长，过程中却稍纵即逝，只有那些创造了丰富记忆的生活，才能在回顾时重新延展时间的维度。 时间绑定效应：感官整合的奇妙现象
我们的大脑会自动将发生在相近时间的事件&amp;rdquo;绑定&amp;rdquo;在一起，创造出一种因果关系的错觉。这种效应在日常生活中无处不在：
当你按下电灯开关后灯亮了，你感知这两个事件是同时发生的，尽管实际上存在微小的延迟。大脑为了创造一个连贯的现实体验，自动调整了时间感知。
这种时间绑定机制让我们能够在嘈杂的环境中将声音和画面正确匹配，让我们相信自己的行动直接导致了后果，让世界在我们眼中变得有秩序、可预测。
大脑不是被动地记录时间，而是主动地创造时间体验，它会为了连贯性和因果关系的需要，悄悄重写时间的细节。
如何掌控你的时间 了解了大脑的时间感知机制，我们就可以有意识地调整自己的时间体验，让生活更加充实且有节奏感。
延缓主观时间的流逝 如果你觉得时间过得太快，可以尝试这些方法：
主动创造新鲜体验：尝试新活动、走不同的路线上班、品尝未曾尝试的食物。新奇性会减慢主观时间流逝，并在回忆中拉长时间。 分段感知时间：将一天分成多个小段，有意识地为每段时间设定不同的活动。研究显示，这样可以增加时间感知的密度。 正念练习：定期练习专注于当下的呼吸和感受，可以增强对时间流逝的感知。 减少&amp;quot;自动驾驶&amp;quot;模式：避免过度依赖日常习惯而不自觉。有意识地感受日常活动，比如刷牙时注意牙刷的触感，走路时感受脚步的节奏。 创造&amp;quot;时间里程碑&amp;quot;：定期安排有纪念意义的活动，它们会成为记忆中的锚点，拉长主观时间的感受。  加速主观时间（特定情况下） 有时候，我们也需要让特定的时间段（如痛苦、等待）感觉更短：
心流状态：全身心投入有挑战性但又不超出能力范围的活动，可以进入&amp;quot;心流&amp;quot;状态，时间感知会大幅加速。 分散注意力：等待时，将注意力转移到其他任务上，可以减少对时间流逝的关注。 细分任务：将大型枯燥任务分解为小块，完成每块时会产生成就感，减轻时间拖沓的感觉。  掌控时间的关键不在于表面的时间管理技巧，而在于理解并调整内在的时间感知。真正的时间智慧，是知道何时让时间流逝得更慢，何时让它溜走得更快。
结语 时间之于我们，既是约束也是可能。它限定了我们存在的边界，却也为我们提供了体验和创造的舞台。真正的智慧不在于对抗时间的流逝，而在于理解并接纳它的本质，进而在其框架内寻找最深刻的存在。</description>
    </item>
    
  </channel>
</rss>