关键词：
为了让大家深入掌握 App 运行时的内存模型，这一节的内容按照由外到内、逐步深入的原则，分为了 3 个部分：
- 内存描述指标
- 内存数据获取
- 内存模型详解
话不多说，让我们马上开始这一章学习吧！
内存描述指标
在进行内存优化之前，我们必须要先熟悉常用的内存描述指标。内存描述指标可以用来度量一个 App 的内存情况，也可以在我们做内存优化时，更直观地展示出优化前后的效果。
常用的内存描述指标有 6 个，我们先来简单了解一下。
- PSS（ Proportional Set Size ）：实际使用的物理内存，会按比例分配共享的内存。比如一个应用有两个进程都用到了 Chrome 的 V8 引擎，那么每个进程会承担 50% 的 V8 这个 so 库的内存占用。PSS 是我们使用最频繁的一个指标，App 线上的内存数据统计一般都取这个指标。
- RSS（ Resident Set Size ）：PSS 中的共享库会按比例分担，但是 RSS 不会，它会完全算进当前进程，所以把所有进程的 RSS 加总后得出来的内存会比实际高。按比例计算内存占用会有一定的消耗，因此当想要高性能的获取内存数据时便可以使用 RSS，Android 的 LowMemoryKiller 机制就是根据每个进程的 RSS 来计算进程优先级的。
- Private Clean / Private Dirty：当我们执行 dump meminfo 时会看到这个指标，Private 内存是只被当前进程独占的物理内存。独占的意思是即使释放之后也无法被其他进程使用，只有当这个进程销毁后其他进程才能使用。Clean 表示该对应的物理内存已经释放了，Dirty 表示对应的物理内存还在使用。
- Swap Pss Dirty：这个指标和上面的 Private 指标刚好相反，Swap 的内存被释放后，其他进程也可以继续使用，所以我们在 meminfo 中只看得到 Swap Pss Dirty，而看不到Swap Pss Clean，因为 Swap Pss Clean 是没有意义的。
- Heap Alloc：通过 Malloc、mmap 等函数实际申请的虚拟内存，包括 Naitve 和虚拟机申请的内存。
- Heap Free：空闲的虚拟内存。
内存描述指标并不多，上面这几个就完全够用了，而且我相信大家或多或少都接触过，所以这里列出来便于我们后面查阅。
内存数据获取
了解了内存的描述指标，我们再来看看如何获取内存的数据，主要有 2 种方式。
① 线下通过 adb 命令获取，一般用于线下调试：
adb shell
dumpsys meminfo 进程名/pid
② 线上通过代码获取，一般用于收集线上的内存数据：
ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
虽然获取方法不同，但这两种方式获取数据的原理完全一样，它们调用的都是 android_os_Debug.cpp 对象中的 android_os_Debug_getDirtyPagesPid 接口，它的源码如下：
static jboolean android_os_Debug_getDirtyPagesPid(JNIEnv *env, jobject clazz,
jint pid, jobject object)
bool foundSwapPss;
stats_t stats[_NUM_HEAP];
memset(&stats, 0, sizeof(stats));
//1\\. 加载maps文件，获取
if (!load_maps(pid, stats, &foundSwapPss))
return JNI_FALSE;
struct graphics_memory_pss graphics_mem;
//2\\. 获取graphics区域内存数据
if (read_memtrack_memory(pid, &graphics_mem) == 0)
stats[HEAP_GRAPHICS].pss = graphics_mem.graphics;
stats[HEAP_GRAPHICS].privateDirty = graphics_mem.graphics;
stats[HEAP_GRAPHICS].rss = graphics_mem.graphics;
stats[HEAP_GL].pss = graphics_mem.gl;
stats[HEAP_GL].privateDirty = graphics_mem.gl;
stats[HEAP_GL].rss = graphics_mem.gl;
stats[HEAP_OTHER_MEMTRACK].pss = graphics_mem.other;
stats[HEAP_OTHER_MEMTRACK].privateDirty = graphics_mem.other;
stats[HEAP_OTHER_MEMTRACK].rss = graphics_mem.other;
//3\\. 获取Unkonw区域数据
for (int i=_NUM_CORE_HEAP; i<_NUM_EXCLUSIVE_HEAP; i++)
stats[HEAP_UNKNOWN].pss += stats[i].pss;
stats[HEAP_UNKNOWN].swappablePss += stats[i].swappablePss;
stats[HEAP_UNKNOWN].rss += stats[i].rss;
stats[HEAP_UNKNOWN].privateDirty += stats[i].privateDirty;
stats[HEAP_UNKNOWN].sharedDirty += stats[i].sharedDirty;
stats[HEAP_UNKNOWN].privateClean += stats[i].privateClean;
stats[HEAP_UNKNOWN].sharedClean += stats[i].sharedClean;
stats[HEAP_UNKNOWN].swappedOut += stats[i].swappedOut;
stats[HEAP_UNKNOWN].swappedOutPss += stats[i].swappedOutPss;
//4\\. 将获取的数据存放到容器中
……
return JNI_TRUE;
这段源码比较长，我们一起来梳理下里面的逻辑，主要分为 4 部分。
-
读取 maps 文件，获取该进程的内存详情：通过上一节的学习，我们知道进程使用的内存都是虚拟内存，并且虚拟内存都以页为维度来管理和维护。这个进程的虚拟内存每一页上存放了什么数据，都会记录在 maps 文件中，maps 文件是一个很重要的文件，后面会详细介绍它。
-
调用 libmemtrack 接口获取 graphics 内存数据：Graphic 内存分配和使用方式具有特殊性，并没有全部映射到应用进程，需要通过 HAL 层（抽象硬件层）libmemtrack 的接口查询，才能完整得到使用的 graphics 内存数据。
-
分配 Unknow 区域的内存数据：根据前面的知识我们知道，mmap 除了做内存映射，还可以用来申请虚拟内存，如果在申请内存时是私有且匿名的（ fd 如果为 -1，flag 入参为MAP_ANONYMOUS 或 MAP_PRIVATE ）就会算入 Unknow 中，如果 mmap 申请内存时指定了申请这段内存的名字，就会算入 Other Dev 当中。因此，对这一区域内存问题的排查往往比较复杂，因为我们不知道内存的来源。
-
存放获取到的内存数据并返回：最后一部分就是将前面获取到的数据放到对应的数据结构中，并返回给接口调用方。
内存模型详解
我们已经知道如何获取内存数据，但是这些数据从哪儿来呢？毕竟只有知道来源，我们才能从源头进行治理。那接下来，我们就对 App 运行时的内存模型进行一个全面且详细的剖析。
我们以系统设置这个 App 为例子，通过 adb 命令获取的内存数据如下：
这里把上面的数据分为两个部分：A 区域和 B 区域。其中 A 区域的数据主要来自前面提到的 android_os_Debug_getMemInfo 接口，B 区域的数据则是对 A 区域中的数据做了汇总处理。
A区域
前面我们已经了解到，android_os_Debug_getMemInfo 接口的数据有两部分来源，一部分是读取 maps 文件解析到每块内存所属的数据，另一部分是读取 libmemtrack 接口的数据获取到的 graphic 内存数据。这两部分的数据来源就组成了 A 区域中的三块数据。下面我们分别来看看这三块数据。
数据 ①：maps 文件数据
maps 文件是分析内存很重要的一个文件，通过 maps 文件我们可以详细知道这个进程的内存中存放了哪些数据。maps 文件存放在 /proc/ pid /maps 路径中，该路径除了存放该进程的 maps 文件，还存放了该进程的所有其他信息的数据。如果你感兴趣可以深入了解一下。
对于 root 的手机，我们可以直接查看该目录下的 maps 文件。但是 maps 文件非常长，直接看会很吃力，所以我们一般会通过脚本对 maps 文件中的数据做分析和归类。下面还是以系统设置这个应用为例，它的 maps 文件的部分内容如下：
图中从左至右各个数据段的解释如下：
| 字段 | address | perms offset | offset | dev | inode | pathname |
|---|---|---|---|---|---|---|
| 数据 | 12c00000-32c00000 | rw-p | 00000000 | 00:00 | 0 | main space (region space)] |
| 含义 | 本段内存映射的虚拟地址空间范围 | 读写权限 | 本段映射地址在文件中的偏移 | 所映射的文件所属设备的设备号 | 文件的索引节点号 | 对有名映射而言，pathname 是映射的文件名；对匿名映射来说，pathname 是此段内存在进程中的作用 |
如果手机没有 root 也没关系，我们可以在运行时通过 native 层的 c++ 代码读取该文件，可以看一下android_os_Debug_getMemInfo 接口中调用的 load_maps 方法，该方法读取 maps 文件后，还做了一个详细的分类操作，分完类之后就是我们看到的数据 ① 中的数据，这个方法比较长，所以我精简了部分代码。
static bool load_maps(int pid, stats_t* stats, bool* foundSwapPss)
*foundSwapPss = false;
uint64_t prev_end = 0;
int prev_heap = HEAP_UNKNOWN;
std::string smaps_path = base::StringPrintf("/proc/%d/smaps", pid);
auto vma_scan = [&](const meminfo::Vma& vma)
int which_heap = HEAP_UNKNOWN;
int sub_heap = HEAP_UNKNOWN;
bool is_swappable = false;
std::string name;
if (base::EndsWith(vma.name, " (deleted)"))
name = vma.name.substr(0, vma.name.size() - strlen(" (deleted)"));
else
name = vma.name;
uint32_t namesz = name.size();
// 解析Native Heap 内存
if (base::StartsWith(name, "[heap]"))
which_heap = HEAP_NATIVE;
else if (base::StartsWith(name, "[anon:libc_malloc]"))
which_heap = HEAP_NATIVE;
else if (base::StartsWith(name, "[anon:scudo:"))
which_heap = HEAP_NATIVE;
else if (base::StartsWith(name, "[anon:GWP-ASan"))
which_heap = HEAP_NATIVE;
// 解析 stack 部分内存
else if (base::StartsWith(name, "[stack"))
which_heap = HEAP_STACK;
else if (base::StartsWith(name, "[anon:stack_and_tls:"))
which_heap = HEAP_STACK;
// 解析 code 部分的内存
else if (base::EndsWith(name, ".so"))
which_heap = HEAP_SO;
is_swappable = true;
else if (base::EndsWith(name, ".jar"))
which_heap = HEAP_JAR;
is_swappable = true;
else if (base::EndsWith(name, ".apk"))
which_heap = HEAP_APK;
is_swappable = true;
else if (base::EndsWith(name, ".ttf"))
which_heap = HEAP_TTF;
is_swappable = true;
else if ((base::EndsWith(name, ".odex")) ||
(namesz > 4 && strstr(name.c_str(), ".dex") != nullptr))
which_heap = HEAP_DEX;
sub_heap = HEAP_DEX_APP_DEX;
is_swappable = true;
else if (base::EndsWith(name, ".vdex"))
which_heap = HEAP_DEX;
……
else if (base::EndsWith(name, ".oat"))
which_heap = HEAP_OAT;
is_swappable = true;
else if (base::EndsWith(name, ".art") || base::EndsWith(name, ".art]"))
which_heap = HEAP_ART;
……
else if (base::StartsWith(name, "/dev/"))
which_heap = HEAP_UNKNOWN_DEV;
// 解析 gl 区域内存
if (base::StartsWith(name, "/dev/kgsl-3d0"))
which_heap = HEAP_GL_DEV;
// 解析 cursor 区域内存
else if (base::StartsWith(name, "/dev/ashmem/CursorWindow"))
which_heap = HEAP_CURSOR;
else if (base::StartsWith(name, "/dev/ashmem/jit-zygote-cache"))
which_heap = HEAP_DALVIK_OTHER;
sub_heap = HEAP_DALVIK_OTHER_ZYGOTE_CODE_CACHE;
//解析ashmen匿名共享内存
else if (base::StartsWith(name, "/dev/ashmem"))
which_heap = HEAP_ASHMEM;
else if (base::StartsWith(name, "/memfd:jit-cache"))
which_heap = HEAP_DALVIK_OTHER;
sub_heap = HEAP_DALVIK_OTHER_APP_CODE_CACHE;
else if (base::StartsWith(name, "/memfd:jit-zygote-cache"))
which_heap = HEAP_DALVIK_OTHER;
sub_heap = HEAP_DALVIK_OTHER_ZYGOTE_CODE_CACHE;
//解析java Heap内存
else if (base::StartsWith(name, "[anon:"))
which_heap = HEAP_UNKNOWN;
if (base::StartsWith(name, "[anon:dalvik-"))
which_heap = HEAP_DALVIK_OTHER;
if (base::StartsWith(name, "[anon:dalvik-LinearAlloc"))
sub_heap = HEAP_DALVIK_OTHER_LINEARALLOC;
else if (base::StartsWith(name, "[anon:dalvik-alloc space") ||
base::StartsWith(name, "[anon:dalvik-main space"))
// This is the regular Dalvik heap.
which_heap = HEAP_DALVIK;
sub_heap = HEAP_DALVIK_NORMAL;
else if (base::StartsWith(name,
"[anon:dalvik-large object space") ||
base::StartsWith(
name, "[anon:dalvik-free list large object space"))
which_heap = HEAP_DALVIK;
sub_heap = HEAP_DALVIK_LARGE;
else if (base::StartsWith(name, "[anon:dalvik-non moving space"))
which_heap = HEAP_DALVIK;
sub_heap = HEAP_DALVIK_NON_MOVING;
else if (base::StartsWith(name, "[anon:dalvik-zygote space"))
which_heap = HEAP_DALVIK;
sub_heap = HEAP_DALVIK_ZYGOTE;
else if (base::StartsWith(name, "[anon:dalvik-indirect ref"))
sub_heap = HEAP_DALVIK_OTHER_INDIRECT_REFERENCE_TABLE;
else if (base::StartsWith(name, "[anon:dalvik-jit-code-cache") ||
base::StartsWith(name, "[anon:dalvik-data-code-cache"))
sub_heap = HEAP_DALVIK_OTHER_APP_CODE_CACHE;
else if (base::StartsWith(name, "[anon:dalvik-CompilerMetadata"))
sub_heap = HEAP_DALVIK_OTHER_COMPILER_METADATA;
else
sub_heap = HEAP_DALVIK_OTHER_ACCOUNTING; // Default to accounting.
else if (namesz > 0)
which_heap = HEAP_UNKNOWN_MAP;
else if (vma.start == prev_end && prev_heap == HEAP_SO)
// bss section of a shared library
which_heap = HEAP_SO;
prev_end = vma.end;
prev_heap = which_heap;
const meminfo::MemUsage& usage = vma.usage;
if (usage.swap_pss > 0 && *foundSwapPss != true)
*foundSwapPss = true;
uint64_t swapable_pss = 0;
if (is_swappable && (usage.pss > 0))
float sharing_proportion = 0.0;
if ((usage.shared_clean > 0) || (usage.shared_dirty > 0))
sharing_proportion = (usage.pss - usage.uss) / (usage.shared_clean + usage.shared_dirty);
swapable_pss = (sharing_proportion * usage.shared_clean) + usage.private_clean;
// 将获取的数据进行累加
……
;
//for循环函数，执行maps文件的读取
return meminfo::ForEachVmaFromFile(smaps_path, vma_scan);
通过上面对 maps 的解析函数，我们不仅可以看到 maps 中的数据类型及格式，也可以知道 Dalvik Heap，Native Heap 等数据的组成。在做内存的线上异常监控时，异常情况下，也可以将 maps 文件上传到服务端，服务端对 maps 文件进行解析和分类，这样我们就能非常方便的定位和排查线上内存问题。
数据②：graphic 相关数据
了解了 maps 文件中的内存数据，我们再来看看 graphic 的数据，graphic 的数据有 3 部分。
-
Gfx dev：绘制时分配，并且已经映射到应用进程虚拟内存中。这里需要注意的是，只有高通的芯片才会将这一块的内存放在 /dev/kgsl-3d0 路径，并映射到进程的虚拟内存中，其他的芯片不会放在这个路径。在上面的 load_maps 方法中，我们也可以看到对这一块内存数据的解析逻辑。
-
GL mtrack：绘制时分配，没有映射到应用地址空间，包括纹理、顶点数据、shader program 等。
-
EGL mtrack：应用的 Layer Surface，通过 gralloc 分配，没有映射到应用地址空间。不熟悉 Layer Surface 的话，可以将一个界面理解成一个 Layer Surface，Surface 存储了界面的数据，并交给 GPU 绘制。
上面 1 的数据是通过 load_maps 函数解析获取的，2 和 3 的数据是通过 read_memtrack_memory 函数获取的。该函数会读取和解析路径为 /d/kgsl/proc/ pid /mem 的文件，这个文件节点中的数据是gpu driver写入的，该方法的实现可以参考下面高通855源码中的 kgsl_memtrack_get_memory 函数，下面是这个函数的主体逻辑代码。（官方源码：kgsl.c）
int kgsl_memtrack_get_memory(pid_t pid, enum memtrack_type type,
struct memtrack_record *records,
size_t *num_records)
……
// 1\\. 设置目标文件路径
snprintf(tmp, sizeof(tmp), "/d/kgsl/proc/%d/mem", pid);
……
while (1)
// 2\\. 读取并解析该文件
……
……
return 0;
我们也可以在 root 手机中，查看 kgsl_memtrack_get_memory 函数读取到该应用进程的数据，下面是系统设置这个应用的部分 graphic 数据。
/d/kgsl/proc/3160 # cat mem
gpuaddr useraddr size id flags type usage sglen mapcount eglsrf eglimg
0000000000000000 0 196608 1 --w---N-- gpumem any(0) 0 0 0 0
0000000000000000 0 16384 2 --w--pY-- gpumem command 0 1 0 0
0000000000000000 0 4096 3 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 4 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 5 --w--pY-- gpumem gl 0 1 0 0
0000000000000000 0 4096 6 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 7 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 20480 8 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 9 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 10 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 196608 11 --w---N-- gpumem any(0) 0 0 0 0
0000000000000000 0 16384 12 --w--pY-- gpumem command 0 1 0 0
0000000000000000 0 4096 13 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 14 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 15 --w--pY-- gpumem gl 0 1 0 0
0000000000000000 0 4096 16 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 17 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 32768 18 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 19 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 20 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 65536 21 --w--pY-- gpumem arraybuffer 0 1 0 0
0000000000000000 0 131072 22 --wl-pY-- gpumem command 0 1 0 0
0000000000000000 0 32768 23 --w--pY-- gpumem gl 0 1 0 0
0000000000000000 0 131072 24 --wl-pY-- gpumem gl 0 1 0 0
0000000000000000 0 8192 25 --w--pY-- gpumem command 0 1 0 0
0000000000000000 0 8192 26 --w--pY-- gpumem command 0 1 0 0
0000000000000000 0 16384 27 --w--pY-- gpumem command 0 1 0 0
0000000000000000 0 9469952 28 --wL--N-- ion egl_surface 152 0 1 1
0000000000000000 0 131072 29 --wl-pY-- gpumem command 0 1 0 0
0000000000000000 0 8192 30 --w--pY-- gpumem command 0 1 0 0
0000000000000000 0 4096 31 -----pY-- gpumem gl 0 1 0 0
0000000000000000 0 4096 32 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 33 -----pY-- gpumem gl 0 1 0 0
0000000000000000 0 4096 34 --w--pY-- gpumem any(0) 0 1 0 0
0000000000000000 0 4096 35 -----pY-- gpumem gl 0 1 0 0
……
数据③：Alloc 内存
在内存描述指标这一部分，我们已经知道数据 ③ 中的数据是调用 malloc、mmap、calloc 等内存申请函数时积累的数据，想要获取这个数据，可以通过下面的接口实现。
- 获取 Java 层申请的内存：会直接去 Art 虚拟机中获取虚拟机已经申请的内存大小。
Runtime runtime = Runtime.getRuntime();
//获取已经申请的Java内存 long usedMemory=runtime.totalMemory() ;
//获取申请但未使用Java内存 long freeMemory = runtime.freeMemory();
- 获取 Native 申请的内存：会调用 android_os_Debug.cpp 对象中的android_os_Debug_getNativeHeapSize 接口获取数据，该接口又是调用的 mallinfo 函数，mallinfo 函数会返回 native 层已经申请的内存大小。
//获取已经申请的Native内存
long nativeHeapSize = Debug.getNativeHeapSize()
//获取申请但未使用Native内存
long nativeHeapFreeSize = Debug.getNativeHeapFreeSize()
//Naitve层
static jlong android_os_Debug_getNativeHeapSize(JNIEnv *env, jobject clazz)
struct mallinfo info = mallinfo();
return (jlong) info.usmblks;
我们可以看下 mallinfo 函数的说明文档：
通过上面两个接口获取 Naitve 和 Java 的内存数据效率最高，性能消耗最小，所以适合在代码中做数据监控使用。通过读取和解析 maps 文件来获取内存数据对性能的开销较大，所以从 Android10 开始加了 5 分钟的频控。
B区域
B 区域的数据就是将 A 区域中的 ① 数据做了汇总操作，方便我们查看，并没有太特别的内容，这里就简单列一下了。
- Java Heap：（Dalvik Heap 的 Private Dirty 数据) + （ .art mmap 部分的 Private Dirty 和 Private Clean 数据) + getOtherPrivate ( OTHER_ART ) 。这里的 .art 是应用的 dex 文件预编译后的 art 文件，所以也是属于该应用的 JavaHeap。
- Native Heap：Native Heap 的 Private Dirty 数据。
- Code：.so .jar .apk .ttf .dex .oat 等资源加总。
- Stack：getOtherPrivateDirty ( OTHER_STACK )。
- Graphics：gl，gfx，egl 的数据加总。
- System：( Total Pss ) - （ Private Dirty 和 Private Clean 的总和）。主要是系统占用的内存，如共享的字体、图像资源等。
小结
想要深入掌握 App 运行时的内存模型，夯实内存优化的基础，首先我们要熟悉描述内存的指标，它们是度量我们内存优化效果的重要工具。
常用的指标有 6 个，分别是共享库按比例分担的 Pss；进程在 RAM 中实际保存的总内存 RSS；只被当前进程独占的物理内存 Private Clean / Private Dirty；和 Private 相反的 Swap Pss Dirty；以及 Heap Alloc 和空闲的虚拟内存 Heap Free。获取这些指标的方法有两个，线下可以通过 adb 命令获取，线上可以通过代码获取。
其次，我们需要从原理上深入了解内存的组成，以及这些组成的来源，这样我们才能在内存优化中，做到有的放矢。我们重点掌握 3 类数据：maps 文件数据、graphic 相关数据和 Alloc 内存。
更多Android 知识点归整
Android 性能调优系列：https://0a.fit/dNHYY
Android 车载学习指南：https://0a.fit/jdVoy
Android Framework核心知识点笔记：https://0a.fit/acnLL
Android 音视频学习笔记：https://0a.fit/BzPVh
Jetpack全家桶（含Compose）：https://0a.fit/GQJSl
Kotlin 入门到精进：https://0a.fit/kdfWR
Flutter 基础到进阶实战：https://0a.fit/xvcHV
Android 八大知识体系：https://0a.fit/mieWJ
Android 中高级面试题锦：https://0a.fit/YXwVq
后续如有新知识点，将会持续更新，尽请期待……
juc学习之共享模型之内存(代码片段)
JUC学习之共享模型之内存Java内存模型可见性退不出的循环解决方法两阶段终止模式interrupt实现volatile实现同步模式之Balking定义实现指令重排有序性指令级并行原理名词ClockCycleTimeCPIIPC鱼罐头的故事指令重排序优化支持流水线的处... 查看详情
jvm内存模型(代码片段)
开始学Java的时候，听到好多都说Java编程不用考虑内存管理，比C方便多了。但是后来看一些基础知识，发现不了解Java各个部分内存分布，有些概念很难理解。JVM内存分为5个部分：方法区，JVM堆，JVM栈，本地方法栈，程序计数器... 查看详情
并发编程系列之什么是java内存模型？(代码片段)
并发编程系列之什么是Java内存模型？1、什么是Java的内存模型Java内存模型简称JMM（JavaMemoryModel），JMM是和多线程并发相关的一组规范。各个jvm实现都要遵循这个JMM规范。才能保证Java代码在不同虚拟机顺利运行。... 查看详情
并发编程系列之什么是java内存模型？(代码片段)
并发编程系列之什么是Java内存模型？1、什么是Java的内存模型Java内存模型简称JMM（JavaMemoryModel），JMM是和多线程并发相关的一组规范。各个jvm实现都要遵循这个JMM规范。才能保证Java代码在不同虚拟机顺利运行。... 查看详情
juc学习之共享模型之内存(代码片段)
JUC学习之共享模型之内存Java内存模型可见性退不出的循环解决方法两阶段终止模式interrupt实现volatile实现同步模式之Balking定义实现指令重排有序性指令级并行原理名词ClockCycleTimeCPIIPC鱼罐头的故事指令重排序优化支持流水线的处... 查看详情
ios之深入解析memory内存(代码片段)
...言iOS是基于BSD发展而来，理解一般的桌面操作系统的内存机制是非常有必要的。在此基础之上，进一步在iOS系统层面进行分析，包括iOS整体的内存机制，以及iOS系统运行时的内存占用的情况。最后会将粒度缩小到i... 查看详情
「性能优化系列」app内存优化理论与实践(代码片段)
...推荐：作者：付十一性能优化系列：启动优化内存优化布局优化卡顿优化apk瘦身优化电量优化项目地址：fuusy/FuPerformance当一个应用同时运行越来越多的任务以及复杂的业务，Android系统的内存管理机制已经无法... 查看详情
android性能优化之内存泄漏检测以及内存优化（下）(代码片段)
上篇博客我们写到了Android中内存泄漏的检测以及相关案例，这篇我们继续来分析一下Android内存优化的相关内容。 上篇：Android性能优化之内存泄漏检测以及内存优化（上）。 中篇：Android性能优化之内... 查看详情
android性能优化之内存泄漏检测以及内存优化（中）(代码片段)
上篇博客我们写到了Java/Android内存的分配以及相关GC的详细分析，这篇博客我们会继续分析Android中内存泄漏的检测以及相关案例，和Android的内存优化相关内容。 上篇：Android性能优化之内存泄漏检测以及内存优化&... 查看详情
ios性能优化之内存优化(代码片段)
近四年没更CSDN了，感慨万千。 近年来在搞一款比较大的APP，项目中代码量100w+，里面使用的三方库、其他领域的二进制包比较多；以前这些三方、二进制都挤在同一个工程目录下，... 查看详情
java虚拟机之内存模型(代码片段)
前言：我们在学习JVM的内存模型的时候，需要先了解JDK相关的知识作为铺垫。一、JDK体系结构1、JDK概念图 JDK：JDK提供了编译、运行Java程序所需的各种资源和工具；包括Java编译器，Java运行时环境【JRE】；... 查看详情
java内存模型和线程安全(代码片段)
Java内存模型和线程安全Java内存模型引言volatile关键字synchronized关键字Java线程Java线程安全synchronized锁优化锁优化技巧列举自旋锁锁消除锁粗化具体实现轻量级锁偏向锁Java内存模型引言对于多核处理器而言,每个核都会有自己单独... 查看详情
内核解读之内存管理内存模型(代码片段)
文章目录1、基本术语2、FLATMEM（平坦内存模型）3、SPARSEMEM稀疏内存模型1、基本术语在介绍内存模型之前需要了解一些基本的知识。1、什么是pageframe？在linux操作系统中，物理内存被分成一页页的pageframe来管理ÿ... 查看详情
并发编程之内存模型(代码片段)
本章要点详细介绍以下几个问题：1、为什么需要内存模型2、什么是内存模型3、内存模型解决什么问题 1、为什么需要内存模型 说道内存模型不得不首先说下目前的计算机组成原理，目前主流的计算机都是冯诺依曼机。... 查看详情
内核解读之内存管理内存模型(代码片段)
文章目录基本的术语CONFIG_FLATMEM（平坦内存模型）稀疏的内存模型基本的术语在介绍内存模型之前需要了解一些基本的知识。1、什么是pageframe？在linux操作系统中，物理内存被分成一页页的pageframe来管理，具体... 查看详情
音视频开发之旅（52)-java并发编程之内存模型与volatile(代码片段)
目录 JVM内存结构和内存模型并发编程中的三个概念与重排序happens-before原则volatile原理volatile使用场景资料收获一、JVM内存结构和内存模型1.1JVM内存结构图片来自图书《深入理解Java虚拟机》Java虚拟机在运行程序时会把其自动管... 查看详情
音视频开发之旅（52)-java并发编程之内存模型与volatile(代码片段)
目录 JVM内存结构和内存模型并发编程中的三个概念与重排序happens-before原则volatile原理volatile使用场景资料收获一、JVM内存结构和内存模型1.1JVM内存结构图片来自图书《深入理解Java虚拟机》Java虚拟机在运行程序时会把其自动管... 查看详情
内存优化之重新认识内存(代码片段)
我们知道，手机的内存是有限的，如果应用内存占用过大，轻则引起卡顿，重则导致应用崩溃或被系统强制杀掉，更严重的情况下会影响应用的留存率。因此，内存优化是性能优化中非常重要的一部分。但... 查看详情