技术

Python ioc 从0到1构建一个db 上下文记忆 agentic chat 图数据库的一些考量 LLM一些探索 Agent实践 LLM预训练 向量数据库的一些考量 fastapi+sqlalchemy进行项目开发 LLM微调实践 Python协程实现 Agent Functon Calling LLamaIndex入门 Multi-Agent探索 Python虚拟机 LLM工作流编排 Python实践 下一个平台Agent 激发LLM涌现——提示工程 LLM微调理论 大佬沉思 LLM外挂知识库 LLMOps 多模态LLM Python一些比较有意思的库 Transformers源码学习 LangChain源码学习 通用分布式计算引擎Ray Python并发 go依赖注入 go collection gc的基本原理 golang性能分析及优化 数据湖 高性能计算与存储 Linux2.1.13网络源代码学习 《大数据经典论文解读》 三驾马车学习 Spark 内存管理及调优 Yarn学习 从Spark部署模式开始讲源码分析 容器狂占内存资源怎么办？ 多角度理解一致性 golang io使用及优化模式 Flink学习 c++学习 学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器以及defer实现 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go堆内存分配 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 共识算法 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 Kubernetes 控制器模型 容器日志采集 容器狂占资源怎么办？ Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 线程排队 jib源码分析之细节 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用？ 串一串一致性协议 当我在说PaaS时，我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 如何分发计算 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂？ 递归、回溯、动态规划 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型和jvm内存布局 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践（二） Thrift基本原理与实践（一） 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring（八） 支持AOP 自己动手写spring（七） 类结构设计调整 分析log日志 自己动手写spring（六） 支持FactoryBean 自己动手写spring（九） 总结 自己动手写spring（五） bean的生命周期管理 自己动手写spring（四） 整合xml与注解方式 自己动手写spring（三） 支持注解方式 自己动手写spring（二） 创建一个bean工厂 自己动手写spring（一） 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle/make使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

bert rerank微调 大模型推理tips RAG向量检索与微调 dddfirework源码分析 RAG与知识图谱 大模型推理服务框架vLLM 大模型推理服务框架 模型服务化（未完成） 大模型Post-Training 大模型训练 大模型推理 从Attention到Transformer k8s设备管理 ddd从理念到代码 如何应用LLM 小鼠如何驾驭大象（LLM）？ 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 kubevela源码分析 容器和CPU那些事儿 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 AutoML和AutoDL 特征平台 实时训练 分布式链路追踪 K8S YAML 资源清单管理方案 tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 推荐系统embedding原理及实践 机器学习中的python调用c 机器学习训练框架概述 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从混部到统一调度 从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tensorflow学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Admission Controller 与 Admission Webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的？ 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI——kubelet与容器引擎之间的接口 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 概率论 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 架构大杂烩 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

Container 23

Concurrency 14

Life 41

Tool 8

Algorithm 8

JVM 10

Go 21

Kubernetes 65

k8s设备管理 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 kubevela源码分析 容器和CPU那些事儿 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 K8S YAML 资源清单管理方案 从混部到统一调度 volcano特性源码分析 kubebuilder 学习 client-go学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 openkruise学习 基于Kubernetes选主及应用 Admission Controller 与 Admission Webhook k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的？ Kubernetes events学习及应用 CRI——kubelet与容器引擎之间的接口 资源调度泛谈 如何学习Kubernetes 以应用为中心 kubernetes operator kubernetes扩缩容 serverless 泛谈 什么是云原生 自定义CNI IPAM docker和k8s安全访问机制 Kubernetes监控 Kubernetes 控制器模型 Kubernetes资源调度——scheduler Kubernetes类型系统 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 Kubernetes源码分析——从kubectl开始 kubernetes yaml配置 CNI——容器网络是如何打通的 当我在说PaaS时，我在说什么 《深入剖析kubernetes》笔记 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件

Other 5

Network 15

Python 8

Java 20

Spring 17

Netty 10

Storage 25

Distribute 9

MQ 8

WEB 5

Linux 11

Scala 1

Code 9

MachineLearning 75

上下文记忆 agentic chat bert rerank微调 大模型推理tips LLM一些探索 Agent实践 LLM预训练 RAG向量检索与微调 LLM微调实践 RAG与知识图谱 大模型推理服务框架vLLM Agent Functon Calling LLamaIndex入门 Multi-Agent探索 LLM工作流编排 大模型推理服务框架 模型服务化（未完成） 大模型Post-Training 大模型训练 大模型推理 从Attention到Transformer 下一个平台Agent 激发LLM涌现——提示工程 LLM微调理论 大佬沉思 LLM外挂知识库 LLMOps 多模态LLM Transformers源码学习 LangChain源码学习 如何应用LLM 小鼠如何驾驭大象（LLM）？ AutoML和AutoDL 特征平台 实时训练 tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 推荐系统embedding原理及实践 机器学习中的python调用c 机器学习训练框架概述 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 推理服务 mpi 学习pytorch 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tensorflow学习 kaggle泰坦尼克问题实践 神经网络模型优化 概率论 直觉上理解深度学习 如何学习机器学习 深度学习泛谈

Practice 16

RPC 6

Compute 11

Architecture 20

DDD 6

Reactive 5

Basic 13

Product 3

Monitor 7

CPP 2

Mesh 12


java内存模型和jvm内存布局

2017年05月02日

前言

Java Memory Model 它是一系列文章 Java Concurrency 中的一篇文章。

Java和操作系统交互细节

为什么会有内存模型一说

Java内存模型：Java中的volatile有什么用？在不同的架构上，缓存一致性问题是不同的，例如 x86 采用了 TSO 模型，它的写后写（StoreStore）和读后读（LoadLoad）完全不需要软件程序员操心，但是 Arm 的弱内存模型就要求我们自己在合适的位置添加 StoreStore barrier 和 LoadLoad barrier。一些代码在 x86 机器上运行是没有问题的，但是在 Arm 机器就有概率打印出 Error。为了解决这个问题，Java 语言在规范中做出了明确的规定，也就是在 JSR 133 文档中规定了 Java 内存模型。内存模型是用来描述编程语言在支持多线程编程中，对共享内存访问的顺序。在 JSR133 文档中，这个内存模型有一个专门的名字，叫 Happens-before，它规定了一些同步动作的先后顺序。JMM 是一种标准规定，它并不管实现者是如何实现它的。纯粹的 JMM 本身的实用性并不强。PS：线程间共享变量 就是 cpu多核共享缓存

Java内存模型深入分析曾经，计算机的世界远没有现在复杂，那时候的cpu只有单核，我们写的程序也只会在单核上按代码顺序依次执行，根本不用考虑太多。后来，随着技术的发展，cpu的执行速度和内存的读写速度差异越来越大，人们很快发现，如果还是按照代码顺序依次执行的话，cpu会花费大量时间来等待内存操作的完成，这造成了cpu的巨大浪费。为了弥补cpu和内存之间的速度差异，计算机世界的工程师们在cpu和内存之间引入了缓存，虽然该方法极大的缓解了这一问题，但追求极致的工程师们觉得这还不够，他们又想到了一个点子，就是通过合理调整内存的读写顺序来进一步缓解这个问题。

  1. 比如，在编译时，我们可以把不必要的内存读写去掉，把相关连的内存读写尽量放到一起，充分利用缓存。
  2. 比如，在运行时，我们可以对内存提前读，或延迟写，这样使cpu不用总等待内存操作的完成，充分利用cpu资源，避免计算能力的浪费。

这一想法的实施带来了性能的巨大提升，但同时，它也带来了一个问题，就是内存读写的乱序，比如原本代码中是先写后读，但在实际执行时却是先读后写，怎么办呢？为了避免内存乱序给上层开发带来困扰，这些工程师们又想到了可以通过分析代码中的语义，把有依赖关系，有顺序要求的代码保持原有顺序，把剩余的没有依赖关系的代码再进行性能优化，乱序执行，通过这样的方式，就可以屏蔽底层的乱序行为，使代码的执行看起来还是和其编写顺序一样，完美。

多核时代的到来虽然重启了计算机世界新一轮的发展，但也带来了一个非常严峻的问题，那就是多核时代如何承接单核时代的历史馈赠。单核运行不可见的乱序，在多核情况下都可见了，且此种乱序已经严重影响到了多核代码的正确编写。默认乱序执行，在关键节点保证有序，这种方式不仅使单核时代的各种乱序优化依然有效，也使多核情况下的乱序行为有了一定的规范。基于此，各种硬件平台提供了自己的方式给上层开发，约定好只要按我给出的方式编写代码，即使是在多核情况下，该保证有序的地方也一定会保证有序。这套在多核情况下，依然可以让开发者指定哪些代码保证有序执行的规则，就叫做内存模型。

内存模型的英文是memory model，或者更精确的来说是memory consistency model，它其实就是一套方法或规则，用于描述如何在多核乱序的情况下，通过一定的方式，来保证指定代码的有序执行。它是介于硬件和软件之间，以一种协议的形式存在的。对硬件来说，它描述的是硬件对外的行为规范，对软件来说，它描述的是编写多线程代码的一套规则。这就衍生出了一个问题，就是不同硬件上的内存模型差异很大，完全不兼容。比如应用于桌面和服务器领域的x86平台用的是x86 tso内存模型。比如应用于手机和平板等移动设备领域的arm平台用的是weakly-ordered内存模型。比如最近几年大火的riscv平台用的是risc-v weak memory ordering内存模型。

深入理解并发编程艺术之内存模型处理器提供了一些特殊指令比如 LOCK，CMPXCHG，内存屏障等来保障多线程情况下的程序逻辑正常执行。但这依然存在几个问题：

  1. 处理器底层指令实现细节复杂难懂，开发人员需要付出巨大的学习成本。
  2. 不同的硬件和操作系统，对指令的支持和实现不一样，需要考虑跨平台的兼容性。
  3. 程序业务逻辑复杂多变，处理器和线程之间的数据操作依赖关系也相应更复杂。

因此高级语言会提供一种抽象的内存模型，用于描述多线程环境下的内存访问行为。无需关心底层硬件和操作系统的具体实现细节，就可以编写出高效、可移植的并发程序。对于 Java 语言，这种内存模型便是 Java 内存模型（Java Memory Model，简称 JMM）。Java 内存模型主要特性是提供了 volatile、synchronized、final 等同步原语，用于实现原子性、可见性和有序性。另一个重要的概念便是 happens-before 关系，用来描述并发编程中操作之间的偏序关系。除了 Java 语言，包括 golang，c++，rust 等高级语言也实现了自己的 happens-before 关系。Java 内存模型定义了主内存（main memory），本地内存（local memory），共享变量等抽象关系，来决定共享变量在多线程之间通信同步方式，即前面所说两个线程操作的内存可见性。其中本地内存，涵盖了缓存，写缓冲区，寄存器以及其他硬件和编译器优化等概念。

如图所示，如果线程 A 与线程 B 之间要通信的话，必须要经历下面 2 个步骤：

  1. 线程 A 把本地内存 A 中更新过的共享变量刷新到主内存中
  2. 线程 B 到主内存中去读取线程 A 之前已更新过的共享变量

硬件层面的内存模型

Java内存模型(Java Memory Model，JMM)JMM和Java运行时数据区没有直接对应关系

  1. 基于高速缓存的存储交互很好的解决了CPU和内存的速度的矛盾，但也引入了一个新的问题，缓存一致性，为了解决这个问题
    1. 总线锁机制，总线锁就是使用CPU提供的一个LOCK#信号，当一个处理器在总线上输出此信号，其他处理器的请求将被阻塞，那么该处理器就可以独占共享锁。
    2. 缓存锁机制，总线锁定开销太大，我们需要控制锁的力度，所以又有了缓存锁，核心就是缓存一致性协议，不同的CPU硬件厂商实现方式稍有不同，有MSI、MESI、MOSI等。
  2. JSR-133规范，即Java内存模型与线程规范。JSR133倾诉的对象有两个，一个是使用者（程序员），另外一个是JMM的实现方（JVM）。面向程序员，JSR133通过happens-before规则给使用者提供了同步语义的保证。面向实现者，JSR133限制了编译器和处理器的优化（禁止处理器重排序，要求Java编译器在生成指令序列时，插入特定类型的内存屏障指令，通过内存屏障指令来禁止特定类型的处理器重排序）。
  3. JMM对特性提供的支持如下： ||volatile关键字|synchronized关键字|Lock接口|Atomic变量| |—|—|—|—|—| |原子性|无法保障|可以保障|可以保障|可以保障| |可见性|可以保障|可以保障|可以保障|可以保障| |有序性|一定程度|可以保障|可以保障|无法保障|

语言层面的内存模型

图解JVM内存模型及JAVA程序运行原理通常，我们编写的Java源代码在编译后会生成一个Class文件，称为字节码文件。Java虚拟机负责将字节码文件翻译成特定平台下的机器代码，然后类加载器把字节码加载到虚拟机的内存中，通过解释器将字节码翻译成CPU能识别的机器码行。简言之，java的跨平台就是因为不同版本的 JVM。JVM与实际机器一样，他有自己的指令集（类似CPU通过指令操作程序运行），并在运行时操作不同的内存区域（JVM内存体系）。JVM位于操作系统之上，与硬件没有直接交互。每一条Java指令，Java虚拟机规范中都有详细定义，如怎么取操作数，怎么处理操作数，处理结果放在哪里。

由于Java的目标是write once, run anywhere，所以它不仅创造性的提出了字节码中间层，让字节码运行在虚拟机上，而不是直接运行在物理硬件上，它还在语言层面内置了对多线程的跨平台支持，也为此提出了Java语言的内存模型，这样，当我们用Java写多线程项目时，只要按照Java的内存模型规范来编写代码，Java虚拟机就能保证我们的代码在所有平台上都是正确执行的。在语言层面支持多线程在现在看来不算什么，但在那个年代，这也算是一项大胆的创举了，它也成为了首个主流编程语言中，内置支持多线程编码的语言。

JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

Java内存模型FAQ（二） 其他语言，像C++，也有内存模型吗？大部分其他的语言，像C和C++，都没有被设计成直接支持多线程。这些语言对于发生在编译器和处理器平台架构的重排序行为的保护机制会严重的依赖于程序中所使用的线程库（例如pthreads），编译器，以及代码所运行的平台所提供的保障。也就是，语言上没有final、volatile 关键字这些，可以对编译器和处理器重排序 施加影响。

Java内存模型FAQ（六）没有正确同步的含义是什么？

java memory model 与 harware memory Architecture

JVM在执行 Java 程序的过程中会把它管理的内存划分为若干个不同的数据区域。每个区域都有各自的作用。

这几张图从粗到细，逐步引出了jvm 内存组成，栈的组成，堆的组成，栈和堆内数据的关系。逐步介绍了 thread stack、call stack（方法栈、栈帧）等概念

cpu ==> 寄存器 ==> cpu cache ==> main memory，cpu cache 由cache line 组成，cache line 是 与 main memory 沟通的基本单位，就像mysql innodb 读取 一行数据时 实际上不是 只读取一行，而是直接读取一页到内存一样。

The hardware memory architecture does not distinguish between thread stacks and heap. On the hardware, both the thread stack and the heap are located in main memory. Parts of the thread stacks and heap may sometimes be present in CPU caches and in internal CPU registers. jvm 和 物理机 对“内存/存储” 有不同的划分，jvm 中没有cpu、cpu core 等抽象存在，也没有寄存器、cpu cache、main memory 的区分，因此 stack、heap 数据 可能分布在 寄存器、cpu cache、main memory 等位置。

When objects and variables can be stored in various different memory areas in the computer, certain problems may occur. The two main problems are:

  1. Visibility of thread updates (writes) to shared variables. 可以用volatile 关键字解决
  2. Race conditions when reading, checking and writing shared variables. 让两个线程 不要同时执行同一段代码，可以用synchronized block 解决，本质就是将竞争转移（从竞争同一个变量 到去竞争 同一个锁）。或者使用cas 保证竞争是原子的。

就着上图 去理解《java并发编程实战》中的有序性、原子性及可见性 ，会有感觉很多。基于JVM的内存结构，看一下程序在JVM内部是怎么运行的：

  1. JAVA源代码编译成字节码；
  2. 字节码校验并把JAVA程序通过类加载器加载到JVM内存中；
  3. 在加载到内存后针对每个类创建Class对象并放到方法区；
  4. 字节码指令和数据初始化到内存中；
  5. 找到main方法，并创建栈帧；
  6. 初始化程序计数器内部的值为main方法的内存地址；
  7. 程序计数器不断递增，逐条执行JAVA字节码指令，把指令执行过程的数据存放到操作数栈中（入栈），执行完成后从操作数栈取出后放到局部变量表中，遇到创建对象，则在堆内存中分配一段连续的空间存储对象，栈内存中的局部变量表存放指向堆内存的引用；遇到方法调用则再创建一个栈帧，压到当前栈帧的上面。

可以脑补一下 基于jvm 内存模型，多线程执行 访问 对象的局部变量 的图，直接的观感是jvm 是从内存（heap）中直接拿数据的，会有原子性问题，但没有可见性问题。但实际上，你根本搞不清楚，从heap 中拿到的对象变量的值 是从寄存器、cpu cache、main memory 哪里拿到的，写入问题类似。jvm 提供volatile 等微操工具，介入两种内存模型的映射过程，来确保预期与实际一致，从这个角度看，jvm 并没有完全屏蔽硬件架构的特性（当然，也是为了提高性能考虑），不过确实做到了屏蔽硬件架构的差异性。

汇编代码中访问 Java 堆、栈和方法区中的数据，都是直接访问某个内存地址或者寄存器，之间并没有看见有什么隔阂。HotSpot 虚拟机本身是一个运行在物理机器上的程序，Java 堆、栈、方法区都在 Java 虚拟机进程的内存中分配（这意思是有一个变量指向堆、栈、方法区？）。在 JIT 编译之后，Native Code 面向的是 HotSpot 这个进程的内存，说变量 a 还在 Java Heap 中，应当理解为 a 的位置还在原来的那个内存位置上，但是 Native Code 是不理会 Java Heap 之类的概念的，因为那并不是同一个层次的概念。

java 内存模型与并发读写控制

Java内存模型深入分析如果程序中存在对同一变量的多个访问操作，且至少有一个是写操作，则这些访问操作被称为是conflicting操作，如果这些conflicting操作没有被happens-before规则约束，则这些操作被称为data race，有data race的程序就不是correctly synchronized，运行时也就无法保证sequentially consistent特性，没有data race的程序就是correctly synchronized，运行时可保证sequentially consistent特性。

happens-before规则由两部分组成，一部分是program order，即单线程中代码的编写顺序，另一部分是synchronizes-with，即多线程中的各种同步原语。也就是说，在单线程中，代码编写的前后顺序之间有happens-before关系，在多线程中，有synchronizes-with关联的代码之间也有happens-before关系。

  1. program order，即单线程中代码的字面顺序
  2. synchronizes-with，即各种同步操作，比如synchronized关键字，volatile关键字，线程的启动关闭操作等。定义多线程之间操作的顺序

极客时间《深入拆解Java虚拟机》

  1. happens-before 关系是用来描述两个操作的内存可见性的。如果操作 X happens-before 操作 Y，那么 X 的结果对于 Y 可见。
  2. 规定的happens-before 关系：Java 内存模型定义了六七种线程间的 happens-before 关系。比如 线程的启动操作（即 Thread.starts()） happens-before 该线程的第一个操作。
  3. 如果需要在没有happen before关系的时候可见，就要用到内存屏障了。Java 内存模型是通过内存屏障来禁止重排序的。语义上，内存屏障之前的所有写操作都要写入内存；内存屏障之后的读操作都可以获得同步屏障之前的写操作的结果。
  4. 应用程序开发者能够轻易地干预/表达不同线程的操作之间的内存可见性，包括锁、volatile 字段、final 字段与安全发布，所有的解决可见性的手段，最终都基于CPU指令lock。

了解Java可见性的本质 非常经典。volatile关键字的本质

  1. 禁止编译重排序；
  2. 插入运行时内存屏障（x86 lock）。
    1. 在每个volatile写操作的前面插入一个StoreStore屏障；
    2. 在每个volatile写操作的后面插入一个StoreLoad屏障；
    3. 在每个volatile读操作的前面插入一个LoadLoad屏障；
    4. 在每个volatile读操作的后面插入一个LoadStore屏障。

L1\2\3 cache解决CPU读写内存效率的问题，但引出了缓存一致性问题；MESI协议解决缓存一致性问题，但加剧了总线占用和资源竞争；store buffer进一步解决CPU效率的问题，但引出了可见性问题；最终可见性问题抛给了开发者，硬件只提供了lock指令。

进程内存布局

JVM 的内存布局和 Linux 进程的内存布局有什么关系？它们是一样的吗？ 推荐细读。

Linux内核基础知识进程内存布局

左右两侧均表示虚拟地址空间，左侧以描述内核空间为主，右侧以描述用户空间为主。右侧底部有一块区域“read from binary image on disk by execve(2)”，即来自可执行文件加载，jvm的方法区来自class文件加载，那么 方法区、堆、栈 便可以一一对上号了。

jvm 作为 a model of a whole computer，便与os 有许多相似的地方，包括并不限于：

  1. 针对os 编程的可执行文件，主要指其背后代表的文件格式、编译、链接、加载 等机制
  2. 可执行文件 的如何被执行，主要指 指令系统及之上的 方法调用等
  3. 指令执行依存 的内存模型

这三者是三个不同的部分，又相互关联，比如jvm基于栈的解释器与jvm 内存模型 相互依存。

JVM内存区域新画法

一个cpu对应一个线程，一个线程一个栈，或者反过来说，一个栈对应一个线程，所有栈组成栈区。我们从cpu的根据pc指向的指令的一次执行开始：

  1. cpu执行pc指向方法区的指令
  2. 指令=操作码+操作数，jvm的指令执行是基于栈的，所以需要从栈帧中的“栈”区域获取操作数，栈的操作数从栈帧中的“局部变量表”和堆中的对象实例数据得到。
  3. 当在一个方法中调用新的方法时，根据栈帧中的对象引用找到对象在堆中的实例数据，进而根据对象实例数据中的方法表部分找到方法在方法区中的地址。根据方法区中的数据在当前线程私有区域创建新的栈帧，切换PC，开始新的执行。

PermGen ==> Metaspace

Permgen vs Metaspace in JavaPermGen (Permanent Generation) is a special heap space separated from the main memory heap.

  1. The JVM keeps track of loaded class metadata in the PermGen.
  2. all the static content: static methods,primitive variables,references to the static objects
  3. bytecode,names,JIT information
  4. before java7,the String Pool

With its limited memory size, PermGen is involved in generating the famous OutOfMemoryError. What is a PermGen leak?

Metaspace is a new memory space – starting from the Java 8 version; it has replaced the older PermGen memory space. The garbage collector now automatically triggers cleaning of the dead classes once the class metadata usage reaches its maximum metaspace size.with this improvement, JVM reduces the chance to get the OutOfMemory error.

其它材料

JSR 133 (Java Memory Model) FAQ及其译文Java内存模型FAQ（一） 什么是内存模型，深入理解Java内存模型（一）——基础系列文章

Java includes several language constructs, including volatile, final, and synchronized, which are intended to help the programmer describe a program’s concurrency requirements to the compiler. The Java Memory Model defines the behavior of volatile and synchronized, and, more importantly, ensures that a correctly synchronized Java program runs correctly on all processor architectures.