内存管理

#include<iostream> #include<boost\weak_ptr.hpp> #include<boost\shared_array.hpp> int main(int argc, char** argv) { boost::shared_ptr<int> sp0(new int(100)); std::cout <<" sp0.use_count == " <<sp0.use_count()<< std::endl; boost::weak_ptr<int> wp0(sp0); std::cout << " wp0.use_count == " << wp0.use_count() << std::endl; if (!wp0.expired()) { boost::shared_ptr<int> sp1 = wp0.lock(); *sp1 = 111; std::cout << " wp0.use_count == " << wp0.use_count() << std::endl; } std::cout << " wp0.use_count == " << wp0.use_count() << std::endl; sp0.reset(); std::cout << " wp0.use_count == " << wp0.use_count() <<

本文作者Pierre是一名有10多年经验的高级系统架构师，他的主要专业领域是Java EE、中间件和JVM技术。根据他多年的工作实践经验，他发现许多性能问题都是由Java堆容量不足和调优引起的。下面他将和大家分享非常实用的5个Java堆优化技巧。 1.JVM：对难以理解的东西产生恐惧感 千万不要以为，通过配置，调优，就可以排除那些你所不明白的问题。有些人认为Java程序员不需要知道内部JVM内存管理。毫无疑问，这种观点明显是错误的，如果想拓宽知识面和提升排除故障能力，你就必须要了解和学习一下JVM内存管理。 对于Java或者是Java EE新手来说，Java Heap调优和故障排除是一项非常有挑战的工作。下面会提供一些典型的案例场景： 客户端环境面临着有规律的OutOfMemoryError错误并且对业务造成了很大的影响。 你的开发团队要在如此大的压力下去解决这个问题，通常会怎么做？ 用谷歌搜索引擎找到类似的问题并且你会相信（或假设）你也面临同样的问题。 你会抓住JVM-Xms和存在OutOfMemoryError异常这几个关键字的例子，然后希望通过这样的案例来快速解决客户端问题。 最后你会在你环境中使用相同的调优方法。两天后，问题仍然发生（甚至更糟或者稍微好点）…… 到底是哪里错了呢？ 首先，没有摸清问题根源所在？对开发环境没有正确地进行深层面（规格、负载情况等）理解

访问 这里 ，获取更多原创内容。 说明：本系列的文章基于Nginx-1.5.0版本代码。 Nginx slab分配器用于管理和分配小于一页的内存申请，但实际上大于一页的内存分配也是统一实现的， 具体代码在core/ngx_slab.c文件中，对应的头文件是core/ngx_slab.h。 ngx_slab.h头文件中定义了两个重要的数据结构： ngx_slab_pool_t；/*整个内存区的管理结构*/ ngx_slab_page_t；/*用于表示page页内存管理单元和slot分级管理单元*/ 同时还声明了对外提供的几个函数原型，分别是： 用于初始化内存管理结构的： void ngx_slab_init(ngx_slab_pool_t *pool); 用于内存分配的： void *ngx_slab_alloc(ngx_slab_pool_t *pool, size_t size); void *ngx_slab_alloc_locked(ngx_slab_pool_t *pool, size_t size); void *ngx_slab_calloc(ngx_slab_pool_t *pool, size_t size); void *ngx_slab_calloc_locked(ngx_slab_pool_t *pool, size_t size); /*alloc 和

glibc下的内存管理 几周前我曾提到，我被项目组分配去做了一些探究linux下内存管理机制的活儿。因为我们的产品遇到了一些与之相关的“诡异”问题。这些问题以及相关情况可以概括如下： 先介绍一下相关的背景。由于我们是3D软件，所以用户经常会有“导入/导出”各种geometry的需求。而一个存储这些数据的文件，可能含有不止一个geometry，而且每个geometry中也可能存在着成千上万个面片/多边形等各种基本元素。这些元素本身都不大，但数量很多。 第一次导入geometry时，会占据大量内存（比如说吧，有1.5G）以上；在不关闭软件而进行各种“清理”操作后，内存却基本不释放；接着再次导入相同的geometry时，内存也没有明显增加；然而如果再进行一次导入操作的话，内存又会被大量占用（约1G以上）。 将以上试验，换成先导入geometry1, 然后清理场景, 再导入geometry2，此时geometry2的内存占用量，要比单独首次导入geometry2时所占用的内存量要小。 valgrind是一款在linux下经常使用检查各种内存管理问题的工具集合。我们用valgrind的memcheck组件进行过专门的内存泄露测试，并未发现明显的泄露情况。 我们的产品在mac平台上也有相应的版本。拿到mac os x上做实验，发现同样的代码，表现并不相同。其中每次清理场景后，都会有可观的内存

一、底层结构 采用三层结构，实际使用中可以方便映射到两层或者三层结构，以适用不同的硬件结构。最下层的申请内存函数get_free_page。之上有三种类型的内存分配函数： 1.kmalloc类型。内核进程使用，基于切片（slab）技术，用于管理小于内存页的内存申请。思想出发点和应用层的内存缓冲池同出一辙。但它针对内核结构，特别处理应用场景固定，不考虑释放。 2.vmalloc类型。内核进程使用。用于申请不连续内存。 3.brk/mmap类型。用户进程使用。malloc/free实现的基础。 二、内存管理的相关函数图 STL -> 内存自动分配和自动回收（C++） | C++ -> new分配内存，delete回收内存 | C -> malloc分配内存，free回收内存 | Unix 系统函数 -> sbrk/brk 分配和回收内存 | Unix底层系统函数 -> mmap/munmap分配回收 （用户层） ---------------------------------------------------------------------------- （内核层） Unix内核函数 kmalloc/vmalloc/get_free_page 三、进程与内存 a.所有进程（执行的程序）都必须占用一定数量的内存 b.对任何一个普通进程来讲，它都会涉及到5种不同的数据段

本文将介绍几则 Java 内存管理的小技巧，让你告别陋习，为自己所编写的Java程序提速。 　　很多人都说“Java完了，只等着衰亡吧!”，为什么呢？最简单的的例子就是Java做的系统时非常占内存!一听到这样的话，一定会有不少人站出来为Java辩护，并举出一堆的性能测试报告来证明这一点。其实从理论上来讲Java做的系统并不比其他语言开发出来的系统更占用内存，那么为什么却有这么多理由来证明它确实占内存呢？两个字，陋习。 　　1、别用new Boolean()。 　　在很多场景中Boolean类型是必须的，比如JDBC中boolean类型的set与get都是通过Boolean 封装 传递的，大部分ORM也是用Boolean来封装boolean类型的，比如： 　　以下是引用片段： 　　ps.setBoolean(“isClosed”，new Boolean(true)); 　　ps.setBoolean(“isClosed”，new Boolean(isClosed)); 　　ps.setBoolean(“isClosed”，new Boolean(i==3)); 　　通常这些系统中构造的Boolean实例的个数是相当多的，所以系统中充满了大量Boolean实例小对象，这是相当消耗内存的。Boolean类实际上只要两个实例就够了，一个true的实例，一个false的实例。 　

手动设置虚拟内存 在默认状态下，是让系统管理虚拟内存的，但是系统默认设置的管理方式通常比较保守，在自动调节时会造成页面文件不连续，而降低读写效率，工作效率就显得不高，于是经常会出现“内存不足”这样的提示，下面就让我们自已动手来设置它吧。 ①用右键点击桌面上的“我的电脑”图标，在出现的右键菜单中选“属性”选项打开“系统属性”窗口。在窗口中点击“高级”选项卡，出现高级设置的对话框 ②点击“性能”区域的“设置”按钮，在出现的“性能选项”窗口中选择“高级”选项卡，打开其对话框。 ③在该对话框中可看到关于虚拟内存的区域，点击“更改”按钮进入“虚拟内存”的设置窗口。选择一个有较大空闲容量的分区，勾选“自定义大小”前的复选框，将具体数值填入“初始大小”、“最大值”栏中，而后依次点击“设置→确定”按钮即可，最后重新启动计算机使虚拟内存设置生效。 转自：百度知道 http://baike.baidu.com/view/976.htm 虚拟内存是计算机系统 内存管理 的一种技术。它使得 应用程序 认为它拥有连续的可用的 内存 （一个连续完整的 地址空间 ），而实际上，它通常是被分隔成多个 物理内存 碎片，还有部分暂时存储在外部 磁盘存储器 上，在需要时进行 数据交换 。 目录 简介 作用 虚拟内存不足的原因 1、感染病毒 2、虚拟内存设置不当 3、系统空间不足 4、因为SYSTEM用户权限设置不当

c++三种管理内存的方式： 一. 自动存储（栈存储） 函数的形参，函数内部声明的变量及结构体变量自动存储在栈里面 在所属函数被调用时自动产生，在函数结束时自动消亡 二. 静态存储（编译器预分配） 每个程序都分配一段静态内存空间，永久存储，在程序开始时建立，程序运行结束时销毁static extern变量。 1，extern关键字 为全局变量（外部变量），在函数和类外部定义，可以在程序任一位置进行访问 1.1 定义性声明 extern 类型 变量名 =初始化表达式 extern double a=1.11； 1.2 引用性声明 extern 类型 变量名； # include <iostream> using namespace std ; void change ( ) ; int main ( ) { //引用性定义extern变量 extern int num ; //调用一次change函数 cout << num << endl ; change ( ) ; cout << num << endl ; } //声明num int num = 0 ; void change ( ) { num + = 3 ; } 三. 动态存储 new 和delete，在*或者堆（heap）； malloc 和free 自由存储空间（free store） 相比于栈

这篇文章我们来谈谈垃圾回收器和程序的虚拟内存、物理内存之间的关系。再谈谈怎样判断你的托管堆是否是健康的；为什么在机器还有大量内存的情况下程序会抛出OutofMemoryException。 垃圾回收和物理内存虚拟内存之间的关系： 如果你对这个话题已经了如指掌，请跳过这一段。 GC需要分配段，有关段的解释请参考《 让垃圾回收器高效工作（一） 》。GC调用VirtualAlloc来分配段空间。这意味着如果你的进程中没有足够的连续空间，分配就失败了。这是一种GC抛出OutOfMemeoryException的合法的情况（精确的说，GC没有抛出异常，抛出异常是执行引擎干的，GC只是在分配失败时返回了NULL）。 经常有人问我这样的问题：“为什么我程序的托管堆只使用了X MB的内存，运行时抛出了OutofMemoryException呢？” 其中XMB比2GB小得多。 记住在.Net程序中有一些内存不是GC消耗的。GC和其他一些东西一样是在竞争虚拟内存的空间。比如：你进程中载入的模块需要占用虚拟内存；有些模块直接调用本机代码分配内存也会消耗虚拟内存（VirtualAlloc，HeapAlloc，C++的new等等）。CLR本身也会有些不通过GC分配消耗的内存，比如jitted代码，一些CLR需要的数据结构等等。通常CLR需要的内存是相当小的。你可以通过SOS的

专题： Linux内存管理专题 关键词： OOM、oom_adj、oom_score、badness 。 Linux内核为了提高内存的使用效率采用过度分配内存(over-commit memory)的办法，造成物理内存过度紧张进而触发OOM机制来杀死一些进程回收内存。 该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽会把该进程杀掉。 1. 关于OOM 内核检测到系统内存不足，在内存分配路径上触发out_of_memory，然后调用select_bad_process()选择一个'bad'进程杀掉，判断和选择一个‘bad'进程的过程由oom_badness()决定。 Linux下每个进程都有自己的OOM权重，在/proc/<pid>/oom_adj里面，范围是-17到+15，取值越高，越容易被杀掉。 下面从几个方便来分析OOM： 触发OOM的条件是什么？ 影响OOM行为有哪些参数？ OOM流程分析。 一个OOM实例的解析。 2. OOM触发路径 在内存分配路径上，当内存不足的时候会触发kswapd、或者内存规整，极端情况会触发OOM，来获取更多内存。 在内存回收失败之后，__alloc_pages_may_oom是OOM的入口，但是主要工作在out_of_memory中进行处理。 由于Linux内存都是以页为单位，所以__alloc_pages