内存映射

何为线程栈空间泄露？ 何为anon内存？ 虚拟内存、物理内存、anon内存的联系 anon与线程的联系 glibc源码库线程创建与销毁anon关系 使用pmap分析虚拟地址空间以及anon内存 何为线程栈空间泄露？ 【栈空间泄露】：简单了说就是，创建了线程，系统分配了内存，但是由于异常操作，没有把之前申请的内存还给操作系统，缓存在进程中，导致这块的内存被占用，系统无法分配内存给其他进程。 从用户角度，线程创建后，未设置线程为detach属性，pthread_detach()、pthread_join()销毁函数。 从内存映射角度，在进程中缓存一些无法利用的anon内存。 从系统栈空间分配角度，这些运行结束但是未销毁的线程，既不放在stack_used队列里，也不放在stack_cache,从而线程栈空间不会被调度到。 何为anon内存？ 仅个人观点，在操作系统上运行进程，其实是经过两次映射。一次是用户程序到系统配置器分配的虚拟内存申请，一次是虚拟地址空间到物理空间地址的映射，如果是第二次映射建立前，在申请物理空间，未填充物理页内容，建立映射后，仅仅代表已经分配了内存anon，ps:物理空间最小管理单元是“页”。 虚拟内存 操作系统给用户程序的假象地址，与物理内存建立映射关系。 物理内存 类似物理存储器DRAM anon内存 1.调用malloc、brk

1. collections容器数据类型 collections模块包含除内置类型list、dict和tuple以外的其他容器数据类型。 1.1 ChainMap搜索多个字典 ChainMap类管理一个字典序列，并按其出现的顺序搜索以查找与键关联的值。ChainMap提供了一个很多的“上下文”容器，因为可以把它看作一个栈，栈增长时发生变更，栈收缩时这些变更被丢弃。 1.1.1 访问值 ChainMap支持与常规字典相同的api来访问现有的值。 import collections a = {'a': 'A', 'c': 'C'} b = {'b': 'B', 'c': 'D'} m = collections.ChainMap(a, b) print('Individual Values') print('a = {}'.format(m['a'])) print('b = {}'.format(m['b'])) print('c = {}'.format(m['c'])) print() print('Keys = {}'.format(list(m.keys()))) print('Values = {}'.format(list(m.values()))) print() print('Items:') for k, v in m.items(): print('{} = {

温馨提示：如果使用电脑查看图片不清晰，可以使用手机打开文章单击文中的图片放大查看高清原图。 Fayson的github： https://github.com/fayson/cdhproject 提示：代码块部分可以左右滑动查看噢 Fayson在前面的文章中介绍过CDH6，参考《Cloudera Enterprise 6正式发布》和《如何在Redhat7.4安装CDH6.0》。CDH6主要集成打包了Hadoop3，包括Hadoop3的一些新特性的官方支持，比如NameNode联邦，纠删码等。纠删码可以将HDFS的存储开销降低约50%，同时与三分本策略一样，还可以保证数据的可用性。本文Fayson主要介绍纠删码的工作原理。 默认情况下，HDFS的数据块都会保存三个副本。副本提供了一种简单而健壮的冗余方式来最大化保证数据的可用性。数据的多副本同时可以尽量保证计算任务的本地化。 但副本方式成本是较高的：默认情况下三副本方式会在存储空间或其他资源(比如写入数据时的网络带宽)中产生200%的开销。对于较少访问的数据集(对集群的I/O影响相对不大)，它们的第二个或者第三个副本会比较少访问，但是仍会消耗相同的存储空间。 因此可以使用纠删码(ErasureCoding)来代替多副本的方式，它使用更少的存储却可以保证相同级别的容错。在典型配置下，与三副本方式相比，EC可以将存储成本降低约50%

1、#{}和${}的区别是什么？ 答：mybatis在处理#{}时，会将sql中的#{}替换为?号，调用PreparedStatement的set方法来赋值； mybatis在处理 $ { } 时，就是把 ${ } 替换成变量的值，完成的是简单的字符串拼接。 补充：在mybatis中使用#{}可以防止sql注入，提高系统安全性。MyBatis排序时使用order by 动态参数时需要注意，用$而不是# 2、Xml映射文件中，除了常见的select|insert|updae|delete标签之外，还有哪些标签？ 答：还有很多其他的标签， 、 、 、 、 ，加上动态sql的9个标签，trim|where|set|foreach|if|choose|when|otherwise|bind等，其中 为sql片段标签，通过 标签引入sql片段， 为不支持自增的主键生成策略标签。 3、最佳实践中，通常一个Xml映射文件，都会写一个Dao接口与之对应，请问，这个Dao接口的工作原理是什么？Dao接口里的方法，参数不同时，方法能重载吗？ 答：Dao接口，就是人们常说的Mapper接口，接口的全限名，就是映射文件中的namespace的值，接口的方法名，就是映射文件中MappedStatement的id值，接口方法内的参数，就是传递给sql的参数。Mapper接口是没有实现类的，当调用接口方法时

高端内存是指物理地址大于 896M 的内存。对于这样的内存，无法在“内核直接映射空间”进行映射。 为什么？ 　　因为 “内核直接映射空间”最多只能从 3G 到 4G，只能直接映射 1G 物理内存，对于大于 1G 的物理内存，无能为力 。 　　实际上，“内核直接映射空间”也达不到 1G， 还得留点线性空间给“内核动态映射空间” 呢。 　　因此，Linux 规定 “内核直接映射空间” 最多映射 896M 物理内存 。 　　对于高端内存，可以通过 alloc_page() 或者其它函数获得对应的 page，但是要想访问实际物理内存，还得把 page 转为线性地址才行（为什么？想想 MMU 是如何访问物理内存的），也就是说，我们需要 为高端内存对应的 page 找一个线性空间，这个过程称为高端内存映射。 高端内存映射有三种方式： 1、 映射到“内核动态映射空间” 　　这种方式很简单，因为通过 vmalloc() ，在“内核动态映射空间”申请内存的时候，就可能从高端内存获得页面（参看 vmalloc 的实现），因此说 高端内存有可能映射到“内核动态映射空间” 中 。 2、 永久内核映射 　　如果是通过 alloc_page() 获得了高端内存对应的 page，如何给它找个线性空间？ 　　 内核专门为此留出一块线性空间，从 PKMAP_BASE 到 FIXADDR_START

这一部分要实现的是对多核处理器的支持，然后实现系统调用只喜欢用户应用创建新的应用，而且还要实现round-robin调度算法 Multiprocessor support jos中对CPU进行了抽象 要描述一个CPU， 需要知道id，运行状态，当前正在运行的进程 所有的cpu数目放在cpus数组中 接下来则是对有多个cpu的处理器的抽象，这里使用了三个结构体，总之是比较乱，目前还不能完全看懂 多核处理器的初始化都在mp_init函数中完成，首先是调用mpconfig函数，主要功能是寻找一个MP 配置条目，然后对所有的CPU进行配置，找到启动的处理器 接下来就是要完成lapic(local advanced programmable interrupt controller) apic主要是为与其连接的处理器传送中断信号 而CPU控制与其相关联的apic需要通过读写其中的寄存器，而读写寄存器则是通过映射IO(memory mapped IO)的方法来实现的 有一些物理内存是与apic的寄存器硬件相连的，这样可以通过读写内存完成对寄存器的读写 JOS中在ULIM之上，预留了4MB的内存空间来映射APIC的寄存器 所以在使用APIC之前首先要完成映射。首先需要调用mmio_map_region函数来实现 mmio_map_region函数的实现 这部分的实现还是比较简单的

这里要实现的就是UNIX标准系统调用中的fork，核心当然是copy on write技术 至于为什么采用copy on write，是因为子进程在被创建之后很可能立刻执行exec()了，之前做的一系列的拷贝是无用功 所以说，当创建一个新的子进程的时候，只需要拷贝父进程的内存映射(页表)就可以了，而且将父进程所有的内存映射页都标记为只读的，这样，当子进程或者父进程尝试去读的时候是安全的，而当尝试去写的时候，就会出发page fault，而在page fault处理例程中，单独将被写入的页(比如说栈)拷贝一份，修改掉发出写行为的进程的页表相应的映射就可以了 所以说，第一步应该先规定或者确立一个page fault处理例程 每个进程需要向内核注册这个处理例程，只需要传递一个函数指针即可 sys_env_set_pgfault_upcall函数 将当前进程的page fault处理例程设置为func指向的函数 Normal and exception stacks in user environments 这里出现了第三个栈，即异常栈 在用户程序正常运行时，出在正常的用户栈上，用户栈顶位于USTACKTOP处 而异常栈则是为了上面设置的异常处理例程设立的。当异常发生时，而且该用户进程注册了该异常的处理例程，那么就会转到异常栈上，运行异常处理例程 到目前位置出现了三个栈：

　　三层架构主要指java项目设计中的持久层，业务层，和表现层。一般的项目开发都遵循这样的设计思想。 　　持久层：用于完成内存数据和磁盘数据的转换。 　　业务层：完成业务处理，将表现层提供的数据处理完后，交由持久层完成数据的保存。 　　表现层：完成数据的提供和数据的展示，并提供给用户流程控制。 　　主要采用的实现方式如下： 　　持久层主要采用Dao模式，建立实体类和数据库的表之间的映射关系，也就是那个类映射那个表，那个属性映射哪个列，而持久层的目的就是完成对象数据和关系数据的转换。 　　业务层采用业务脚本模式，将一个业务中所有的操作封装成一个方法，保证这个方法的所有数据库更新操作同时成功同时失败，避免出现部分成功部分失败的问题，引起数据混乱的现象。 　　表现层采用了mvc模式：m即模型，也就是使用实体类封装数据并进行传输。v即视图，也就是窗体和GUI，用于数据的提供和数据的展示。c即控制，也就是事件，调用业务方法，以及业务流程的控制。 来源： https://www.cnblogs.com/Freebe/p/6853851.html

1.字符集 ASCII码 一字节；包括英文数字这些符号 GB2312编码 汉字为两字节；与ASCII码兼容，后来扩展汉字又有了GBK编码 Unicode编码 包括中，日，韩，英文等格式；有Utf-32，Utf-16，Utf-8三种格式 Utf-32：每个字符都采用4字节（32bit），缺点浪费空间 Utf-16（错一个字符则整个乱码）：每个字符的长度为2字节（16bit），常用 Utf-8（容错能力强）：每个字符的长度为1~4字节，越常用的字符越短 一般一个文件的开头都会有标志，通过16进制编辑文件便可看到 Utf-8： EF BB BF Utf-16：FE FE Utf-32：FF FE 没有前缀的表示ANSI格式（GBK） 2.文件的格式不同，执行的结果也不同 3.如何解决文件格式不同，编码也不同的问题？ eg： gcc -finput-charset=GBK -fexec-charset=UTF-8 -o utf-8_2 ansi.c 告诉gcc编译器该文件是GBK编码，需要转换为UTF-8编码后在编译 注： -finput-charset= ？ // 表示源文件的编码格式，默认UTF-8 -fexec-charset= ？ // 表示可执行程序里的字以什么方式表示，默认UTF-8 4.点阵显示 说明： 这里字符选用8*16（内核中有），汉字HZK16*16（自己找库） 链接

1.两种DMA映射类型 1.1. 一致性DMA映射（Consistent DMA mappings ） 主要用于映射长时间使用的区域。 CPU和DMA controller不需要考虑cache的影响。 这里的consistent实际上是coherent的概念，不能保证consistent，也就是说需要memory barrier来保证memory order。 1.2 流式DMA映射（streaming DMA mapping） 主要用于一次性DMA传输，传输完成后就会释放。 2.指定DMA设备的寻址范围 include/linux/dma-mapping.h 1 // 用于一致性内存映射的映射范围 2 static inline int dma_set_coherent_mask(struct device *dev, u64 mask) 3 // 用于流式内存映射的映射范围 4 static inline int dma_set_mask(struct device *dev, u64 mask); 3.DMA映射接口 3.1一致性DMA接口 分配较大DMA buffer 1 // dev DMA控制器设备 2 // size 要分配的DMA buffer大小 3 // dma_handle 返回DMA buf的物理地址 4 // flag 分配标志 5 // 返回值 DMA