共 49 篇相关文章
我们公司上海的工作室的一个 MMO 项目做服务器压力测试。谈及优化，涉及到服务器中使用的 C 模块。他们把同一套 C++ 加上 namespace 编译了很多份，供多个服务使用。我很好奇，一般来说，Lua 的 C 模块是可以供多个 vm 共用的，并不需要实际链接很多份。仔细探究发现，原来这个代码中用到了一些全局对象（singleton 模式）。 我本能的觉得全局对象的设计中透着糟糕的味道，在逐个分析每个全局对象的必要性时，发现了一个有趣的东西：寻路模块。 寻路模块本身的实现是没有持久状态的，场景地图的障碍信息是独立出去的静态不变数据，全局共享，这是合理的设计。但是一个无状态的 pathfinding 对象却被实例化了很多份，供不同的服务独立使用。
随着 Web 应用复杂程度越来越高，以及 NodeJS 大规模投入生产环境，许多 Web 应用都会长时间运行， JavaScript 的内存管理显得更为重要。 JavaScript 具备自动回收垃圾的机制， 执行环境会负责管理代码在执行环境过程中使用的内存，将某些不再被使用的的变量所占用的内存释放掉，正因如此，大多数情况我们在前端开发的时候，并不是那么关注我们的页面用了多少内存，是否合理，需不需要优化。 JavaScript 基础中有很多重要的知识点是和内存相关的，比如深拷贝和浅拷贝、闭包、原型、引用数据类型和引用传递等。
在Android 中的卡顿丢帧原因概述 - 系统篇 这篇文章中 , 实际案例这里我们有列举一些由于系统低内存导致的卡顿 , 由于 Android 低内存对整机性能影响比较大 , 所以单独些一篇文章 , 来概述系统低内存对整机性能的影响 . 随着 Android 系统版本的更迭 , 以及 App 的代码膨胀 , Android 系统对内存的需求越来越大 , 但是目前市面上还存在着大量的 4G 内存以下的机器 , 这部分用户就很容易遇到整机低内存的情况 , 尤其是在系统大版本更新和 App 越装越多的情况下 . Android 低内存会导致性能问题 , 具体表现就是响应慢和卡顿 . 比如启动一个应用要花比平时更长的时间 ; 滑动列表会掉更多帧 ; 后台的进程减少导致冷启动变多 ; 手机很容易发热发烫等 , 下面我会概述发生这些性能问题的原因 . Debug 的方法 , 以及可能的优化措施 .
由于存在线程本地内存和主内存的原因，再加上重排序，会导致多线程环境下存在可见性的问题。那么我们正确使用同步、锁的情况下，线程A修改了变量a何时对线程B可见？ 我们无法就所有场景来规定某个线程修改的变量何时对其他线程可见，但是我们可以指定某些规则，这规则就是happens-before，从JDK 5 开始，JMM就使用happens-before的概念来阐述多线程之间的内存可见性。
在执行程序时，为了提供性能，处理器和编译器常常会对指令进行重排序，但是不能随意重排序，不是你想怎么排序就怎么排序，它需要满足以下两个条件： 1、在单线程环境下不能改变程序运行的结果； 2、存在数据依赖关系的不允许重排序； 如果看过LZ上篇博客的就会知道，其实这两点可以归结于一点：无法通过happens-before原则推导出来的，JMM允许任意的排序。
通过happens-before原则和volatile的内存语义两个方向介绍volatile。
DCL，即Double Check Lock，中卫双重检查锁定。其实DCL很多人在单例模式中用过，LZ面试人的时候也要他们写过，但是有很多人都会写错。他们为什么会写错呢？其错误根源在哪里？有什么解决方案？下面就随LZ一起来分析。
根据目前网络上技术文档的内容，我相信绝大多数了解一点Linux的人应该处在第二种层次。大家普遍认为，buffers和cached所占用的内存空间是可以在内存压力较大的时候被释放当做空闲空间用的。但真的是这样么？
前言 在Java语言开发过程中，out of memory错误是很常见的一种错误。对于JVM的内存结构有更深入的了解，更更好的帮我们排查此类问题，有效的避免此类问题发生。在JAVA 8中内存结构有进行了改变，Metaspace替代了PermGen。
在做网络安全事件分析的时候，都会遇到内存寻址的知识，例如上次跟大家分享的《 空指针漏洞防护技术》，就涉及到非法访问内存地址的问题。如果这个坎儿迈不过去，你就会迷失在代码中，更无从分析了。今天绿盟科技的安全技术专家就讲讲这个内存寻址的原理，文章分为上下两篇《内存寻址原理》及《内存寻址方式》。
相對 C/C++ 而言，我們所用的 JavaScript 在內存這一方面的處理已經讓我們在開發中更注重業務邏輯的編寫。但是隨著業務的不斷複雜化，單頁面應用、移動 HTML5 應用和 Node.js 程序等等的發展，JavaScript 中的內存問題所導致的卡頓、內存溢出等現象也變得不再陌生。
内核中最初勾引我好奇心的还是内存管理方面，我们平时编写应用程序时，一个进程所能拥有的内存大小几乎可以趋近于物理内存最大值或是超越这个值，虽然知道内核做内存方面的映射或是swap然后向我们的用户空间呈现出所谓的虚拟内存，但还是对其中实现疑惑甚多，一些关于内存的名词也是有许多，什么虚拟地址，内核线性地址，内核逻辑地址，balablabla...
正在运行的程序，叫进程。每个进程都有完全属于自己的，独立的，不被干扰的内存空间。此空间，被分成几个段(Segment),分别是Text, Data, BSS, Heap, Stack。用户进程内存空间，也是系统内核分配给该进程的VM(虚拟内存)，但并不表示这个进程占用了这么多的RAM(物理内存)。这个空间有多大？命令top输出的VIRT值告诉了我们各个进程内存空间的大小(进程内存空间随着程序的执行会增大或者缩小)。你还可以通过/proc//maps，或者pmap -d 了解某个进程内存空间都分布。
TCP协议栈内存是不可交换物理内存，用一字节少一字节。也正是由于这一点，操作系统出厂的时候上面的默认的内存设置都不算太大。对于一个不是网络密集型的服务器问题不大，但是对于如承担C1M链接的服务器来讲，问题就来了。我们在实践中会发现tcp服务经常超时，有时候超过100ms. 那么这个问题如何定位呢？
前几天 纯上 同学问了一个问题： 我ps aux看到的RSS内存只有不到30M，但是free看到内存却已经使用了7,8G了，已经开始swap了，请问ps aux的实际物理内存统计是不是漏了哪些内存没算？我有什么办法确定free中used的内存都去哪儿了呢？ 这个问题不止一个同学遇到过了，之前子嘉同学也遇到这个问题，内存的计算总是一个迷糊账。
主要对一般docId为下标对应域值的结构做了改造，如果大家有更好的建议，欢迎大家提议和拍砖。 主要思路： 生成一个下标为 域 Term 遍历的Postion 且值为域值的数组: A[p]=field value 因为域值并不会像docId一样为唯一键递增，所以在创建的时候 初始化: Int [] A = new Int[reader.maxDoc()] 结束的时候如果 p
大型的服务器，特别是数据库服务器的主要瓶颈主要在内存，CPU，以及IO上。CPU是可再生资源，不够用等等就有了；内存和土地一样是不可再生资源，被占用了，后续的使用必须等到该资源释放.而IO也非常依赖于内存的使用情况,故内存的倒腾效率会大大影响服务器的效率,那么了解服务器内存的使用情况就非常重要。 Linux内核的内存相关的信息主要有下面几个获取管道，这里我们主要讨论的是系统级别的，没具体到各个进程级别： 1. 内核启动时候，VM内存相关模块初始化信息，透过dmesg查看。
iOS平台的内存使用引用计数的机制，并且引入了半自动释放机制；这种使用上的多样性，导致开发者在内存使用上非常容易出现内存泄漏和内存莫名的增长情况； 本文会介绍iOS平台的内存使用原则与使用陷阱； 深度剖析autorelease机制；低内存报警后的处理流程；并结合自身实例介绍内存暴增的问题追查记录以及相关工具的使用情况； iOS平台内存常见问题作为iOS平台的开发者，是否曾经为内存问题而苦恼过？内存莫名的持续增长，程序莫名的crash，难以发现的内存泄漏，这些都是iOS平台内存相关的常见问题；本文将会详细介绍iOS平台的内存管理机制，autorelease机制和内存的使用陷阱，这些将会解决iOS平台内存上的大部分问题，提高了程序的稳定性；
在C语言中，如果存在malloc，则一定要有free，否则就会产生内存泄露；而且你还不能free两次，否则，程序将直接崩溃。写PHP程序就比较方便了，你甚至不需要初始化变量，你从来也不用考虑内存回收的问题，但是缺点就是PHP的效率相比C来讲就低多了。我不知道这种比较是否恰当，我想说的是，有一种内存回收是必须显示地、手动地；有一种内存回收是程序自动探测的。前者效率高很多，但是程序开发的效率就很低了；后者开发效率高，但...
今天吃晚饭的时候想到，我需要一个定制的内存分配器。主要是为了解决 共享内存 中的字符串池的管理。 这个内存分配器需要是非入侵式的，即不在要分配的内存块中写 cookie 。 而我的需求中，需要被管理的内存块都是很规则的，成 2 的整数次幂的长度。buddy memory allocation 刚好适用。 算法很简单，就是每次把一个正内存块对半切分，一直切到需要的大小分配出去。回收的时候，如果跟它配对的块也是未被使用的，就合并成一个大...
