当前位置：首页 > news >正文

Linux--环境变量

news 2025/3/29 2:01:22

ok，今天我们来学习Linux中的环境变量、地址空间、虚拟内存

环境变量

基本概念

环境变量(environmentvariables)⼀般是指在操作系统中⽤来指定操作系统运⾏环境的⼀些参数
如：我们在编写C/C++代码的时候，在链接的时候，从来不知道我们的所链接的动态静态库在哪里，但是照样可以链接成功，⽣成可执⾏程序，原因就是有相关环境变量帮助编译器进⾏查找。
环境变量通常具有某些特殊⽤途，还有在系统当中通常具有全局特性

常见环境变量

PATH:指定命令的搜索路径
HOME:指定⽤⼾的主工作目录(即⽤⼾登陆到Linux系统中时,默认的⽬录)
SHELL:当前Shell,它的值通常是/bin/bash。

查看环境变量

echo $NAME //NAME:你的环境变量名称

测试PATH

1. 创建hello.c⽂件

#include<stdio.h>int main()
{printf("hello world!\n");return 0;
}

2. 对比 . / hello执行和直接 hello执⾏

3. 为什么有些指令可以直接执⾏，不需要带路径，⽽我们的⼆进制程序需要带路径才能执⾏？

4. 将我们的程序所在路径加⼊环境变量PATH当中, export PATH=$PATH : hello 程序所在路径

5. 对比测试

6. 还有什么方法可以不用带路径，直接就可以执行呢？

测试HOME

1. ⽤root和普通⽤⼾，分别执⾏ echo $HOME , 对⽐差异

2. 执⾏ cd ~; pwd , 对应 ~ 和 HOME 的关系

和环境变量相关的命令

echo:显⽰某个环境变量值
export: 设置⼀个新的环境变量
env: 显⽰所有环境变量
unset: 清除环境变量
set: 显⽰本地定义的shell变量和环境变量

环境变量的组织方式

每个程序都会收到⼀张环境表，环境表是⼀个字符指针数组，每个指针指向⼀个以 ’\0’ 结尾的环境字符串

通过代码获取环境变量

命令⾏第三个参数

 #include <stdio.h>int main(int argc, char *argv[], char *env[]){int i = 0;for(; env[i]; i++){printf("%s\n", env[i]);}return 0;
}

通过第三方变量environ获取

#include <stdio.h>int main(int argc, char *argv[]){extern char **environ;int i = 0;for(; environ[i]; i++){printf("%s\n", environ[i]);}return 0;}

libc中定义的全局变量environ指向环境变量表,environ没有包含在任何头⽂件中,所以在使⽤时要⽤ extern声明。

通过系统调⽤获取或设置环境变量

putenv
getenv

#include <stdio.h>
#include <stdlib.h>
int main()
{printf("%s\n", getenv("PATH"));return 0;
}

常⽤getenv和putenv函数来访问特定的环境变量。

环境变量通常是具有全局属性的

环境变量通常具有全局属性，可以被⼦进程继承下去

#include <stdio.h>
#include <stdlib.h>
int main()
{char *env = getenv("MYENV");if(env){printf("%s\n", env);}return 0;
}

直接查看，发现没有结果，说明该环境变量根本不存在

导出环境变量 export MYENV="hello world"
再次运⾏程序，发现结果有了！说明：环境变量是可以被⼦进程继承下去的！

如果只进⾏ MYENV ＝ “helloworld” ,不调⽤export导出，在⽤我们的程序查看，会有什么结果？为什么？

当我们登录的时候->bash->读取环境变量配置文件->PATH，HOME ->bash也是一个进程->cwd->

cwd总是继承bash的当前路径的！

环境变量可以被子进程继承

环境变量可以被所有bash之后的进程全部看到，所以环境变量具有“全局属性”。

为什么？

a系统的配置信息，尤其是具有指导性的配置信息，他是系统配置起效的一种表现

b进程具有独立性！环境变量可以用来进程间传递数据（只读数据）

取消unset

程序地址空间

进程的空间布局

虚拟地址/线性地址

 #include <stdio.h>#include <unistd.h>#include <stdlib.h>int g_val = 0;int main(){pid_t id = fork();if(id < 0){perror("fork");return 0;}else if(id == 0){ //childprintf("child[%d]: %d : %p\n", getpid(), g_val, &g_val);}else{ //parentprintf("parent[%d]: %d : %p\n", getpid(), g_val, &g_val);}sleep(1);return 0;
}

输出


//与环境相关，观察现象即可parent[2995]: 0 : 0x80497d8
child[2996]: 0 : 0x80497d8

我们发现，输出出来的变量值和地址是⼀模⼀样的，很好理解呀，因为⼦进程按照⽗进程为模版，⽗⼦并没有对变量进⾏进⾏任何修改。可是将代码稍加改动:

 #include <stdio.h>#include <unistd.h>#include <stdlib.h>int g_val = 0;int main(){pid_t id = fork();if(id < 0){perror("fork");return 0;}else if(id == 0){ //child⼦进程肯定先跑完，也就是⼦进程先修改，完成之后，⽗进程再读取g_val=100;printf("child[%d]: %d : %p\n", getpid(), g_val, &g_val);}else{ //parentsleep(3);printf("parent[%d]: %d : %p\n", getpid(), g_val, &g_val);}sleep(1);return 0;
}

child[3046]: 100 : 0x80497e8
parent[3045]: 0 : 0x80497e8

我们发现，父子进程，输出地址是⼀致的，但是变量内容不⼀样！能得出如下结论:

变量内容不⼀样,所以⽗⼦进程输出的变量绝对不是同⼀个变量
但地址值是⼀样的，说明，该地址绝对不是物理地址！
在Linux地址下，这种地址叫做虚拟地址
我们在⽤C/C++语⾔所看到的地址，全部都是虚拟地址！物理地址，⽤⼾⼀概看不到，由OS统⼀管理

OS必须负责将 虚拟地址转化成 物理地址。

进程地址空间

所以之前说‘程序的地址空间’是不准确的，准确的应该说成进程地址空间，如图

上⾯的图就足以说明问题，同⼀个变量，地址相同，其实是虚拟地址相同，内容不同其实是被映射到了不同的物理地址！

OS在规划进程的时候其实是按照所有的内存空间来进行设计，其地址空间实际是虚拟空间，虚拟空间通过页表一一映射到真实的内存空间。

这样避免进程直接接触内存空间，产生不必要的错误，每一个进程的理想空间都一样，方便管理（如果一个进程挨着一个，进程结束又释放，直接操作内存空间会很繁琐，乱）

页表

先创建内核数据结构，再从磁盘中加载代码程序先描述再组织

虚拟地址 || 物理地址 || 权限(rwx) || 是否在内存中(isexists)

分批加载、挂起等操作

现在重新认识一下进程

进程 = 内核数据结构（task_struct/mm_struct/页表）+ 自己的代码和数据

内核数据结果各自一份，代码和数据也是独立的

text代码区 .rodata只读数据区

结构体变量，必须初始化

可执行区域编译的时候，代码区的大小和各个区域的大小就已经知道了

操作系统（进程管理）和编译器、编译原理、可执行程序都有关系

代码在编译完成时，堆区、栈区、已/未初始化数据区（磁盘加载）、命令行测试环境变量是不存在的，只有在加载进程时，被操作系统动态创建的！！！

栈区

存储局部变量、函数参数、返回地址

堆区

存储动态分配的内存（如 new 或 malloc 分配的内存）

申请空间，堆区扩大，申请更多的虚拟地址创建页表，在使用通过页表申请物理空间

虚拟内存

描述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_MMUstruct vm_region *vm_region;        /* NOMMU mapping region */#endif#ifdef CONFIG_NUMAstruct mempolicy *vm_policy;        /* NUMA policy for the VMA */#endifstruct vm_userfaultfd_ctx vm_userfaultfd_ctx;} __randomize_layout;

为什么要有虚拟地址空间

这个问题其实可以转化为：如果程序直接可以操作物理内存会造成什么问题？

在早期的计算机中，要运⾏⼀个程序，会把这些程序全都装⼊内存，程序都是直接运⾏在内存上的，也就是说程序中访问的内存地址都是实际的物理内存地址。当计算机同时运⾏多个程序时，必须保证这些程序⽤到的内存总量要⼩于计算机实际物理内存的⼤⼩。那当程序同时运⾏多个程序时，操作系统是如何为这些程序分配内存的呢？例如某台计算机总的内存⼤⼩是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感知！！
因为⻚表的映射的存在，程序在物理内存中理论上就可以任意位置加载。它可以将地址空间上的虚拟地址和物理地址进⾏映射，在进程视⻆所有的内存分布都可以是有序的。

1. 虚拟空间+页表：保护内存
虚拟地址和物理地址之间有页表，需要转换和保护，用户层无法直接使用物理内存

野指针，其实是虚拟地址，野指针指向的虚拟地址不对（权限或者地址），系统就会杀掉该进程。

2. 进程管理和内存管理在系统层面进行解耦合
页表将进程管理和内存管理解耦合

3. 让进程以统一的视角看待物理内存
物理内存不存在读写权限，而是由页表控制

可执行程序的代码和数据，是加载到物理内存的任意位置，(特殊情况除外)，因为是由页表控制地址映射和权限

所以进程就可以将物理内存 “无序”变成“有序”

地址空间本质上是一个struct mm_struct

操作系统只要管理好进程，地址空间就管理好了

全局变量、字符常量----全局性，在程序运行期间都会有效

原因是全局变量、字符常量是存储在mm_struct中的全局数据区而不是堆区栈区，会随着进程，一直存在。进程不结束，该区域空间不释放。全局变量的虚拟地址，一直被大家看到。