Linux_进程概念(B)-环境变量&进程地址空间【Linux】
文章目录
- 一、环境变量
- 1、基本概念
- 2、常见环境变量
- 3、查看环境变量方法
- 4、和环境变量相关的命令
- 5、环境变量的组织方式
- 6、通过代码如何获取环境变量
- 7、通过系统调用获取或设置环境变量
- getenv()
- putenv()
- 8、环境变量通常是具有全局属性的
- 9、实验
- 二、程序地址空间
- 1、研究平台
- 2、程序地址空间回顾
- 3、虚拟地址
- 4、进程地址空间
- 5、虚拟内存管理 - 第一讲
- 6、为什么要有虚拟地址空间
一、环境变量
1、基本概念
- 环境变量(environment variables)一般是指在操作系统中用来指定操作系统运行环境的一些参数
- 如：我们在编写C/C++代码的时候，在链接的时候，从来不知道我们的所链接的动态静态库在哪里，但是照样可以链接成功，生成可执行程序，原因就是有相关环境变量帮助编译器进行查找。
- 环境变量通常具有某些特殊用途，还有在系统当中通常具有全局特性
2、常见环境变量
- PATH : 指定命令的搜索路径
- HOME : 指定用户的主工作目录(即用户登陆到Linux系统中时,默认的目录)
- SHELL : 当前Shell,它的值通常是/bin/bash。
3、查看环境变量方法
echo $NAME //NAME:你的环境变量名称
测试PATH
- 创建hello.c文件
#include - 对比
./hello执行和之间hello执行 - 为什么有些指令可以直接执行，不需要带路径，而我们的二进制程序需要带路径才能执行？
- 将我们的程序所在路径加入环境变量PATH当中,
export PATH=$PATH:hello程序所在路径 - 对比测试
- 还有什么方法可以不用带路径，直接就可以运行呢？
测试HOME
- 用root和普通用户，分别执行
echo $HOME,对比差异 - 执行
cd ~; pwd,对应~和HOME的关系
4、和环境变量相关的命令
- echo: 显示某个环境变量值
- export: 设置一个新的环境变量
- env: 显示所有环境变量
- unset: 清除环境变量
- set: 显示本地定义的shell变量和环境变量
5、环境变量的组织方式
每个程序都会收到一张环境表，环境表是一个字符指针数组，每个指针指向一个以’ ’结尾的环境字符串
6、通过代码如何获取环境变量
- 命令行第三个参数
#include - 通过第三方变量environ获取
#include libc中定义的全局变量environ指向环境变量表,environ没有包含在任何头文件中,所以在使用时 要用extern声明。
7、通过系统调用获取或设置环境变量
我们常用getenv和putenv函数来访问特定的环境变量。
getenv()
该函数用来获取指定名称的环境变量值。其原型通常定义于
#include 参数:
- name: 环境变量名字符串
- 返回值: 如果找到相应的环境变量，则返回指向存储此环境变量值的指针；如果未找到则返回 NULL。
示例代码：
#include 这个例子将打印出当前进程中设置的 “PATH” 的内容。
putenv()
它用于修改现有的环境变量或者添加新的环境变量到环境中去。需要注意的是，传递给它的字符串会被直接加入到环境列表中，并且不应该释放或更改这条内存直到程序结束为止。
头文件包含声明如下所示：
#include 参数:
- string: 格式为“NAME=VALUE”的C语言风格字符串
- 返回值: 成功时返回0 ，错误情况返回非零整数。
例如增加一个新的名为MY_VAR的新变量设值hello world:
if( putenv((char *)"MY_VAR=Hello World") == 0 )
{
puts("Successfully added environment variable MY_VAR.");
}
else
{
perror("Error adding environment variable");
}
重要提示:
使用putenv时要注意传入字符串的安全性和生命周期管理。最好总是拷贝一份独立副本再提交给putenv处理以免意外破坏原有数据结构！
8、环境变量通常是具有全局属性的
- 环境变量通常具有全局属性，可以被子进程继承下去
#include 直接查看，发现没有结果，说明该环境变量根本不存在
- 导出环境变量
export MYENV="hello world" - 再次运行程序，发现结果有了！说明：环境变量是可以被子进程继承下去的！想想为什么？
9、实验
• 如果只进行 MYENV＝“helloworld” ,不调用export导出，在用我们的程序查看，会有什么结果？为什么？
• 普通变量
• 如果时间允许：做一下~/.bash_profile && ~/.bashrc修改文件级环境变量
二、程序地址空间
1、研究平台
- kernel 2.6.32
- 32位平台
2、程序地址空间回顾
我们在学C语言的时候，应该见过这样的空间布局图
可是我们对他并不理解！可以先对其进行各区域分布验证：
#include 运行结果:
$ ./a.out
code addr: 0x40055d
init global addr: 0x601034
uninit global addr: 0x601040
heap addr: 0x1791010
heap addr: 0x1791030
heap addr: 0x1791050
heap addr: 0x1791070
test static addr: 0x601038
stack addr: 0x7ffd0f9a4368
stack addr: 0x7ffd0f9a4360
stack addr: 0x7ffd0f9a4358
stack addr: 0x7ffd0f9a4350
read only string addr: 0x400800
argv[0]: 0x7ffd0f9a4811
env[0]: 0x7ffd0f9a4819
env[1]: 0x7ffd0f9a482e
env[2]: 0x7ffd0f9a4845
env[3]: 0x7ffd0f9a4850
env[4]: 0x7ffd0f9a4860
env[5]: 0x7ffd0f9a486e
env[6]: 0x7ffd0f9a4892
env[7]: 0x7ffd0f9a48a5
env[8]: 0x7ffd0f9a48ae
env[9]: 0x7ffd0f9a48f1
env[10]: 0x7ffd0f9a4e8d
env[11]: 0x7ffd0f9a4ea6
env[12]: 0x7ffd0f9a4f00
env[13]: 0x7ffd0f9a4f13
env[14]: 0x7ffd0f9a4f24
env[15]: 0x7ffd0f9a4f3b
env[16]: 0x7ffd0f9a4f43
env[17]: 0x7ffd0f9a4f52
env[18]: 0x7ffd0f9a4f5e
env[19]: 0x7ffd0f9a4f93
env[20]: 0x7ffd0f9a4fb6
env[21]: 0x7ffd0f9a4fd5
env[22]: 0x7ffd0f9a4fdf
3、虚拟地址
来段代码感受一下
#include 输出
//与环境相关，观察现象即可
parent[2995]: 0 : 0x80497d8
child[2996]: 0 : 0x80497d8
我们发现，输出出来的变量值和地址是一模一样的，很好理解呀，因为子进程按照父进程为模版，父子并没有对变量进行进行任何修改。可是将代码稍加改动：
#include 输出结果：
//与环境相关，观察现象即可
child[3046]: 100 : 0x80497e8
parent[3045]: 0 : 0x80497e8
我们发现，父子进程，输出地址是一致的，但是变量内容不一样！能得出如下结论:
- 变量内容不一样,所以父子进程输出的变量绝对不是同一个变量
- 但地址值是一样的，说明，该地址绝对不是物理地址！
- 在Linux地址下，这种地址叫做
虚拟地址 - 我们在用C/C++语言所看到的地址，全部都是虚拟地址！物理地址，用户一概看不到，由OS统一管理
OS必须负责将 虚拟地址 转化成 物理地址 。
4、进程地址空间
所以之前说‘程序的地址空间’是不准确的，准确的应该说成 进程地址空间 ，那该如何理解呢？看图：
分页&虚拟地址空间
说明:
- 上面的图就足矣说明问题，同一个变量，地址相同，其实是虚拟地址相同，内容不同其实是被映射到了不同的物理地址！
5、虚拟内存管理 - 第一讲
描述linux下进程的地址空间的所有的信息的结构体是 mm_struct （内存描述符）。每个进程只有一个mm_struct结构，在每个进程的task_struct结构中，有一个指向该进程的结构。
struct task_struct
{
/*...*/
struct mm_struct *mm; //对于普通的⽤⼾进程来说该字段指向他的
// 虚拟地址空间的⽤⼾空间部分，对于内核线程来说这部分为NULL。
struct mm_struct *active_mm; // 该字段是内核线程使⽤的。当该
// 进程是内核线程时，它的mm字段为NULL，表⽰没有内存地址空间，可也并不是真正的没有，这是因为所有进程关于内核的映射都是⼀样的，内核线程可以使⽤任意进程的地址空间。
/*...*/
}
可以说，mm_struct结构是对整个用户空间的描述。每一个进程都会有自己独立的mm_struct，这样每一个进程都会有自己独立的地址空间才能互不干扰。先来看看由task_struct到mm_struct，进程的地址空间的分布情况：
定位mm_struct文件所在位置和task_struct所在路径是一样的，不过他们所在文件是不一样的， mm_struct所在的文件是mm_types.h。
struct mm_struct
{
/*...*/
struct vm_area_struct *mmap; /* 指向虚拟区间(VMA)链表 */
struct rb_root mm_rb; /* red_black树 */
unsigned long task_size; /*具有该结构体的进程的虚拟地址空间的⼤⼩*/
/*...*/
// 代码段、数据段、堆栈段、参数段及环境段的起始和结束地址。
unsigned long start_code, end_code, start_data, end_data;
unsigned long start_brk, brk, start_stack;
unsigned long arg_start, arg_end, env_start, env_end;
/*...*/
}
那既然每一个进程都会有自己独立的mm_struct，操作系统肯定是要将这么多进程的mm_struct组织起来的！虚拟空间的组织方式有两种：
- 当虚拟区较少时采取单链表，由mmap指针指向这个链表；
- 当虚拟区间多时采取红黑树进行管理，由mm_rb指向这棵树。
linux内核使用 vm_area_struct 结构来表示一个独立的虚拟内存区域(VMA)，由于每个不同质的虚拟内存区域功能和内部机制都不同，因此一个进程使用多个vm_area_struct结构来分别表示不同类型的虚拟内存区域。上面提到的两种组织方式使用的就是vm_area_struct结构来连接各个VMA，方便进程快速访问。
struct vm_area_struct
{
unsigned long vm_start; //虚存区起始
unsigned long vm_end; //虚存区结束
struct vm_area_struct *vm_next, *vm_prev; //前后指针
struct rb_node vm_rb; //红⿊树中的位置
unsigned long rb_subtree_gap;
struct mm_struct *vm_mm; //所属的 mm_struct
pgprot_t vm_page_prot;
unsigned long vm_flags; //标志位
struct
{
struct rb_node rb;
unsigned long rb_subtree_last;
}shared;
struct list_head anon_vma_chain;
struct anon_vma *anon_vma;
const struct vm_operations_struct *vm_ops; //vma对应的实际操作
unsigned long vm_pgoff; //⽂件映射偏移量
struct file * vm_file; //映射的⽂件
void * vm_private_data; //私有数据
atomic_long_t swap_readahead_info;
#ifndef CONFIG_MMU
struct vm_region *vm_region; /* NOMMU mapping region */
#endif
#ifdef CONFIG_NUMA
struct mempolicy *vm_policy; /* NUMA policy for the VMA */
#endif
struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
} __randomize_layout;
所以我们可以对上图在进行更细致的描述，如下图所示：
6、为什么要有虚拟地址空间
这个问题其实可以转化为：如果程序直接可以操作物理内存会造成什么问题？
在早期的计算机中，要运行一个程序，会把这些程序全都装入内存，程序都是直接运行在内存上的，也就是说程序中访问的内存地址都是实际的物理内存地址。当计算机同时运行多个程序时，必须保证这些程序用到的内存总量要小于计算机实际物理内存的大小。
那当程序同时运行多个程序时，操作系统是如何为这些程序分配内存的呢？例如某台计算机总的内存大小是128M，现在同时运行两个程序A和B，A需占用内存10M，B需占用内存110。计算机在给程序分配内存时会采取这样的方法：先将内存中的前10M分配给程序A，接着再从内存中剩余的118M中划分出110M分配给程序B。
这种分配方法可以保证程序A和程序B都能运行，但是这种简单的内存分配策略问题很多。
- 安全风险
: : 每个进程都可以访问任意的内存空间，这也就意味着任意一个进程都能够去读写系统相关内存区域，如果是一个木马病毒，那么他就能随意的修改内存空间，让设备直接瘫痪。 - 地址不确定
: : 众所周知，编译完成后的程序是存放在硬盘上的，当运行的时候，需要将程序搬到内存当中去运行，如果直接使用物理地址的话，我们无法确定内存现在使用到哪 里了，也就是说拷贝的实际内存地址每一次运行都是不确定的，比如：第一次执行a.out时候，内存当中一个进程都没有运行，所以搬移到内存地址是0x00000000，但是第二次的时候，内存已经有10个进程在运行了，那执行a.out的时候，内存地址就不一定了 - 效率低下
: : 如果直接使用物理内存的话，一个进程就是作为一个整体（内存块）操作的，如果出现物理内存不够用的时候，我们一般的办法是将不常用的进程拷贝到磁盘的交换分区中，好腾出内存，但是如果是物理地址的话，就需要将整个进程一起拷⾛，这样，在内存和磁盘之间拷贝时间太长，效率较低。
存在这么多问题，有了虚拟地址空间和分页机制就能解决了吗？当然！
- 地址空间和页表是OS创建并维护的！是不是也就意味着，凡是想使用地址空间和页表进行映射，也一定要在OS的监管之下来进行访问！！也顺便保护了物理内存中的所有的合法数据 ，包括各个进程以及内核的相关有效数据!
- 因为有地址空间的存在和页表的映射的存在，我们的物理内存中可以对未来的数据进行任意位置的加载！物理内存的分配 和 进程的管理就可以做到没有关系，进程管理模块和内存管理模块就完成了解耦合。
: : 因为有地址空间的存在，所以我们在C、C++语言上new, malloc空间的时候，其实是在地址空间上申请的，物理内存可以甚至一个字节都不给你。而当你真正进行对物理地址空间访问的时候，才执行内存的相关管理算法，帮你申请内存，构建页表映射关系（延迟分配），这是由操作系统自动完成，用户包括进程完全0感知！！ - 因为页表的映射的存在，程序在物理内存中理论上就可以任意位置加载。它可以将地址空间上的虚拟地址和物理地址进行映射，在进程视⻆所有的内存分布都可以是有序的。
