内存映射

面试笔记–海量数据题目处理总结 何谓海量数据处理？ 所谓海量数据处理，无非就是基于海量数据上的存储、处理、操作。何谓海量，就是数据量太大，所以导致要么是无法在较短时间内迅速解决，要么是数据太大，导致无法一次性装入内存。 那解决办法呢?针对时间，我们可以采用巧妙的算法搭配合适的数据结构，如Bloom filter/Hash/bit-map/堆/数据库或倒排索引/trie树，针对空间，无非就一个办法：大而化小，分而治之（hash映射），你不是说规模太大嘛，那简单啊，就把规模大化为规模小的，各个击破不就完了嘛。 至于所谓的单机及集群问题，通俗点来讲，单机就是处理装载数据的机器有限(只要考虑cpu，内存，硬盘的数据交互)，而集群，机器有多辆，适合分布式处理，并行计算(更多考虑节点和节点间的数据交互)。 海量数据处理的方法 处理海量数据问题，无非就是 6 种方法： 分而治之/hash映射 + hash统计 + 堆/快速/归并排序； 分而治之/hash映射：针对数据太大，内存受限，只能把大文件化成(取模映射)小文件 hash_map统计：当大文件转化了小文件，那么我们便可以采用常规的hash_map(key，value)来进行频率统计。 堆/快速排序：统计完了之后，便进行排序(可采取堆排序)，得到次数最多的key。 多层划分 多层划分—-其实本质上还是分而治之的思想，重在“分”的技巧上！

1.mybatis的延迟加载 问题：在一对多中，当我们有一个用户，他有100个账户 在查询用户的时候，要不要把关联的账户查出来？ 在查询账户的时候，要不要把关联的用户查出来？ 解决：在查询用户的时候，用户下的账户信息应该是，什么时候使用，什么时候查询出来，如果每次查询用户的时候都把关联的账户信息查询出来，会浪费内存空间 但是在查询账户时，账所属的用户信息应该是随着账户查询时一起查询出来 1.1.什么是延迟加载： 延迟加载：在真正使用数据时才发起查询，不用的时候不查询，所以是按需加载（懒加载）。 1.2.延迟加载的优缺点 延迟加载的好处：先从单表查询，需要时再从关联表去关联查询，大大提高数 据库性能，因为查询单表要比关联查询多张表速度要快。 延迟加载的坏处：因为只有当需要用到数据时，才会进行数据库查询，这样在大批量数据查询时，因为查询工作也要消耗 时间，所以可能造成用户等待时间变长，造成用户体验下降。 2.多对一、一对一延迟加载的实现 使用assocation实现延迟加载 需求：查询账户信息同时查询用户信息 2.1 账户的持久层 DAO 接口 public interface IAccountDao { /** *查询所有账户，同时获取账户的所属用户名称以及它的地址信息 * @return */ List<Account> findAll(); } 2.2. 账户的持久层映射文件 <

1.MFC 消息 只有继承CCmdTarget的类才能实现消息映射。 消息映射应该首先在类里面使用 DECLARE_MESSAGE_MAP(), 然后再类的实现文件里使用 BEGIN_MESSAGE_MAP(theClass, baseClass) END_MESSAGE_MAP() 现在看看怎样实现消息映射的 (注意不同版本的vs实现的上面的宏可能会有微小的差异) ： DECLARE_MESSAGE_MAP()为这个类引入了函数 GetMessageMap()的声明； BEGIN_MESSAGE_MAP 给这个类引入了 _messageEntries 数组(也被称为消息映射数组)，也实现了GetMessageMap() . END_MESSAGE_MAP() 作为 数组_messageEntries 的结束标志。 _messageEntries数组的每一项存储的内容是 消息ID和这个消息的处理函数 。 GetMessageMap() 得到的是一个struct，它的内容是 基类的GetMessageMap()函数的地址 和 自己的_messageEntries数组的地址。 这样当一个消息来到的时候，如果在自己的 消息映射数组(既是_messageEntries) 里面没有找到这个消息处理函数，那么就会调用GetMessageMap() 间接得到父类的消息映射数组(

---- MFC是Windows下程序设计的最流行的一个类库，但是该类库比较庞杂，尤其是它的消息映射机制，更是涉及到很多低层的东西，我们在这里，对它的整个消息映射机制进行了系统的分析，可以帮助程序开发人员对MFC的消息映射机制有一个比较透彻的了解。 1．引言 ---- VC++的MFC类库实际上是Windows下C++编程的一套最为流行的类库。MFC的框架结构大大方便了程序员的编程工作，但是为了更加有效、灵活的使用MFC编程，了解MFC的体系结构往往可以使编程工作事半功倍。它合理的封装了WIN32 API函数，并设计了一套方便的消息映射机制。但这套机制本身比较庞大和复杂，对它的分析和了解无疑有助于我们写出更为合理的高效的程序。这里我们简单的分析MFC的消息响应机制，以了解MFC是如何对Windows的消息加以封装，方便用户的开发。 2. SDK下的消息机制实现 ---- 这里简单的回顾一下SDK下我们是如何进行Windows的程序开发的。一般来说，Windows的消息都是和线程相对应的。即Windows会把消息发送给和该消息相对应的线程。在SDK的模式下，程序是通过GetMessage函数从和某个线程相对应的消息队列里面把消息取出来并放到一个特殊的结构里面，一个消息的结构是一个如下的STRUCTURE。 typedef struct tagMSG { HWND hwnd; UINT

任何一个用过或学过C的人对malloc都不会陌生。大家都知道malloc可以分配一 段连续的内存空间，并且在不再使用时可以通过free释放掉。但是，许多程序员对malloc背后的事情并不熟悉，许多人甚至把malloc当做操作系统 所提供的系统调用或C的关键字。实际上，malloc只是C的标准库中提供的一个普通函数，而且实现malloc的 基本 思想并不复杂，任何一个对C和操作系统有些许了解的程序员都可以很容易理解。 这篇文章通过实现一个简单的malloc来描述malloc背后的机制。当然与现有C的标准库实现（例如glibc）相比，我们实现的malloc 并不是特别高效，但是这个实现比目前真实的malloc实现要简单很多，因此易于理解。重要的是，这个实现和真实实现在基本原理上是一致的。 这篇文章将首先介绍一些所需的基本知识，如操作系统对进程的内存管理以及相关的系统调用，然后逐步实现一个简单的malloc。为了简单起见，这篇文章将只考虑x86_64体系结构，操作系统为Linux。 1 什么是malloc 2 预备知识 2.2.1 内存排布 2.2.2 Heap内存模型 2.2.3 brk与sbrk 2.2.4 资源限制与rlimit 2.1.1 虚拟内存地址与物理内存地址 2.1.2 页与地址构成 2.1.3 内存页与磁盘页 2.1 Linux内存管理 2.2 Linux进程级内存管理

问题描述 一个大小为3的缓冲区，初始为空 2个生产者随机等待一段时间，往缓冲区添加数据，若缓冲区已满，等待消费者取走数据后再添加，重复6次 3个消费者随机等待一段时间，从缓冲区读取数据，若缓冲区为空，等待生产者添加数据后再读取，重复4次 说明： 显示每次添加和读取数据的时间及缓冲区里的数据 生产者和消费者用进程模拟 思路 这道题目涉及到的知识点有： 进程控制管理，包括进程的创建与销毁等 进程通信技术，如管道、共享内存等 解决思路主要是： 一个主进程负责创建和销毁子进程，负责创建共享内存区和公用信号量 五个子进程，两个是生产者，三个是消费者，通过信号量对共享内存进行互斥读写 创建互斥访问量 创建信号量如下： 信号量：EMPTY, FILLED, RW 初始化：EMPTY=3,FILLED=0,RW=1 说明： EMPTY 信号量指示缓冲区有多少个空位置没有被占用，因此初始值等于缓冲区数量； FILLED 指示缓冲区有多少个位置被占用，因此初始值等于0； RW 指示是否允许对共享内存进行读写操作，为防止进程并发执行导致的数据共享错误，每次仅允许一个进程对共享内存进行操作，因此初始值为1. 生产者消费者执行操作 生产者 P(EMPTY);//首先询问是否有空闲缓冲区,没有则阻塞，等待消费者拿出数据释放一个缓冲区；有则EMPTY-=1 P(RW);//是否可以对共享内存进行读写操作

目录 前言 标签 select insert|update|delete 参数 resultMap cache 自定义缓存 # 加入战队 微信公众号 前言 映射器之前我们已经提到了，是mybatis特有的组件： java+xml组合的方式。对于Java类和xml的编写也很简单。值得注意的是需要将Java编写的mapper注册到mybatis中来。之前的注册的方式通过xml。到后续通过spirng来管理通过@Mapper就很方便了。 标签 Java实现的接口Mapper很简单，就是已接口的形式暴露，方法和参数和我们正常的写一样，就是在多参数的时候我们需要通过 @Param 注解标注在sql中的变量名。 但是xml就需要按照mybatis的格式来写了。xml中有select、insert、update、delete等对应方法的标签。除了这些还有sql、resultMap、 select 严格来说，select及下面的insert这些都有一个id,这些id形成JavaMapper中对应的方法。mybatis也是通过id来定位到要执行的sql的。我们通过parameterType、resultType定义入参和出参的类型。Type也可以事先定义为对应的Map 即 parameterMap、resultMap。 在select标签中还有一个flushCache用来表示是否清楚缓存在查询

1、用户编制程序时使用的地址称为 虚地址或逻辑地址 ，其对应的存储空间称为虚存空间或逻辑地址空间；而计算机物理内存的访问地址则称为实地址或物理地址，其对应的存储空间称为物理存储空间或主存空间。 2、虚拟存储器的 容量限制 ：主存容量+辅存（硬盘）容量。 3、 物理内存： 在应用中，真实存在的，插在主板内存槽上的内存条的容量的大小。从本质上来说，物理内存是代码和数据在其中运行的窗口。 4、 虚拟内存： 使程序认为它拥有连续的可用的内存（一个连续完整的地址空间），而实际上，它通常是被分隔成多个物理内存碎片，还有部分暂时存储在外部磁盘存储器上，在需要时进行数据交换。 若计算机运行程序或操作所需的随机存储器(RAM)不足时，则 Windows 会用虚拟存储器进行补偿，即拿出一部分硬盘空间来充当内存使用，这部分空间即称为虚拟内存，虚拟内存在硬盘上的存在形式就是 PAGEFILE.SYS这个页面文件。它将计算机的RAM和硬盘上的临时空间组合。将数据移入分页文件可释放RAM，以便完成工作。 若计算机的速率由于RAM可用空间匮乏而减缓，则可尝试通过增加虚拟内存来进行补偿。但是，计算机从RAM读取数据的速率要比从硬盘读取数据的速率快，因而扩增RAM容量（可加内存条）是最佳选择。 分页文件：硬盘上一个或者多个隐藏文件pagefile.sys，Windows用于存储未存入内存的部分程序和数据文件

将Web项目与文件分开存储，在请求的url中，通过tomcat将指定的虚拟路径指向真实的磁盘文件路径，此为虚拟目录映射。 在进行虚拟目录映射的时候,一般都会进行如下部署 <Context path="/cmw/staticFile" docBase="H:\javaFile\cmw" debug="0" reloadbale="true"/> Linux下docBase的路径表示方式 <Context path="/transhelper/staticFile" docBase="/mnt/static/transhelper" debug="0" reloadable="true"/> 解释 path是虚拟路径； docBase 是应用程序的物理路径； reloadable 如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化，自动装载新的应用程序，可以在不重起tomcat的情况下改变应用程序，实现 热部署 注意: 如果工程中有静态类或者预读取的 配置文件 改掉，那tomcat是必须要重启的，否则无法更新内存，一般的修改，eclipse是自动后台发布的，机理应该是基于文件发布时间的判定。 比如访问 <Host name="localhost" appBase="webapps" unpackWARs="true"

很早之前，就有关于“每台机器（machine)应该有多少个服务”的讨论。在我们继续之 前，应该找一个比“机器”更好的术语。在前虚拟化时代，单个运行操作系统的主机与底 层物理基础设施之间的映射形式有很多种。因此，我倾向于使用“主机”（host)这个词来 做通用的隔离单元，也就是能够运行服务的一个操作系统。如果你直接在物理机上部署， 那么一台物理机映射到一台主机（在当前上下文中，这个词可能不完全正确，但确实也找 不到更好的了）。如果你使用了虚拟化，单个物理机会映射到多个独立的主机，并且每个 都可以包含一个或者多个服务。 所以在考虑不同的部署模型时，我会使用主机这个词。那么每台主机应该有多少个服 务呢？ 我有自己倾向的模型，但要考虑多个因素，来决定哪个模型最适合你。需要注意的一点 是：某些决定会限制可用的部署方式。 6.9.1单主机多服务 如图6-6所示，在每个主机上部署多个服务是很有吸引力的。首先，从主机管理的角度来 看它更简单。在一个团队管理基础设施，另一个团队管理软件的模式下，管理基础设施团 队的工作量通常与所要管理的主机量成正比。如果单个主机包含更多的服务，那么主机管 理的工作量不会随着服务数量的增加而增加。其次是关于成本。即使你有一个能够提供一 些配置和更改虚拟主机大小等服务的虚拟化平台，虚拟化的基础设施本身也会占用一部分 资源，从而减少服务可用的资源。在我看来