开发十年经验总结,阿里架构师的手写Spring boot原理实践文档
阿里架构师的这份:Redis核心原理与应用实践,带你手撕Redis
Tomcat结构原理详解
说到进程,恐怕面试中最常见的问题就是线程和进程的关系了,那么先说一下答案: 在 Linux 系统中,进程和线程几乎没有区别 。
Linux 中的进程其实就是一个数据结构,顺带可以理解文件描述符、重定向、管道命令的底层工作原理,最后我们从 *** 作系统的角度看看为什么说线程和进程基本没有区别。
首先,抽象地来说,我们的计算机就是这个东西:
这个大的矩形表示计算机的 内存空间 ,其中的小矩形代表 进程 ,左下角的圆形表示 磁盘 ,右下角的图形表示一些 输入输出设备 ,比如鼠标键盘显示器等等。另外,注意到内存空间被划分为了两块,上半部分表示 用户空间 ,下半部分表示 内核空间 。
用户空间装着用户进程需要使用的资源,比如你在程序代码里开一个数组,这个数组肯定存在用户空间;内核空间存放内核进程需要加载的系统资源,这一些资源一般是不允许用户访问的。但是注意有的用户进程会共享一些内核空间的资源,比如一些动态链接库等等。
我们用 C 语言写一个 hello 程序,编译后得到一个可执行文件,在命令行运行就可以打印出一句 hello world,然后程序退出。在 *** 作系统层面,就是新建了一个进程,这个进程将我们编译出来的可执行文件读入内存空间,然后执行,最后退出。
你编译好的那个可执行程序只是一个文件,不是进程,可执行文件必须要载入内存,包装成一个进程才能真正跑起来。进程是要依靠 *** 作系统创建的,每个进程都有它的固有属性,比如进程号(PID)、进程状态、打开的文件等等,进程创建好之后,读入你的程序,你的程序才被系统执行。
那么, *** 作系统是如何创建进程的呢? 对于 *** 作系统,进程就是一个数据结构 ,我们直接来看 Linux 的源码:
task_struct 就是 Linux 内核对于一个进程的描述,也可以称为「进程描述符」。源码比较复杂,我这里就截取了一小部分比较常见的。
我们主要聊聊 mm 指针和 files 指针。 mm 指向的是进程的虚拟内存,也就是载入资源和可执行文件的地方; files 指针指向一个数组,这个数组里装着所有该进程打开的文件的指针。
先说 files ,它是一个文件指针数组。一般来说,一个进程会从 files[0] 读取输入,将输出写入 files[1] ,将错误信息写入 files[2] 。
举个例子,以我们的角度 C 语言的 printf 函数是向命令行打印字符,但是从进程的角度来看,就是向 files[1] 写入数据;同理, scanf 函数就是进程试图从 files[0] 这个文件中读取数据。
每个进程被创建时, files 的前三位被填入默认值,分别指向标准输入流、标准输出流、标准错误流。我们常说的「文件描述符」就是指这个文件指针数组的索引 ,所以程序的文件描述符默认情况下 0 是输入,1 是输出,2 是错误。
我们可以重新画一幅图:
对于一般的计算机,输入流是键盘,输出流是显示器,错误流也是显示器,所以现在这个进程和内核连了三根线。因为硬件都是由内核管理的,我们的进程需要通过「系统调用」让内核进程访问硬件资源。
PS:不要忘了,Linux 中一切都被抽象成文件,设备也是文件,可以进行读和写。
如果我们写的程序需要其他资源,比如打开一个文件进行读写,这也很简单,进行系统调用,让内核把文件打开,这个文件就会被放到 files 的第 4 个位置,对应文件描述符 3:
明白了这个原理, 输入重定向 就很好理解了,程序想读取数据的时候就会去 files[0] 读取,所以我们只要把 files[0] 指向一个文件,那么程序就会从这个文件中读取数据,而不是从键盘:
同理, 输出重定向 就是把 files[1] 指向一个文件,那么程序的输出就不会写入到显示器,而是写入到这个文件中:
错误重定向也是一样的,就不再赘述。
管道符其实也是异曲同工,把一个进程的输出流和另一个进程的输入流接起一条「管道」,数据就在其中传递,不得不说这种设计思想真的很巧妙:
到这里,你可能也看出「Linux 中一切皆文件」设计思路的高明了,不管是设备、另一个进程、socket 套接字还是真正的文件,全部都可以读写,统一装进一个简单的 files 数组,进程通过简单的文件描述符访问相应资源,具体细节交于 *** 作系统,有效解耦,优美高效。
首先要明确的是,多进程和多线程都是并发,都可以提高处理器的利用效率,所以现在的关键是,多线程和多进程有啥区别。
为什么说 Linux 中线程和进程基本没有区别呢,因为从 Linux 内核的角度来看,并没有把线程和进程区别对待。
我们知道系统调用 fork() 可以新建一个子进程,函数 pthread() 可以新建一个线程。 但无论线程还是进程,都是用 task_struct 结构表示的,唯一的区别就是共享的数据区域不同 。
换句话说,线程看起来跟进程没有区别,只是线程的某些数据区域和其父进程是共享的,而子进程是拷贝副本,而不是共享。就比如说, mm 结构和 files 结构在线程中都是共享的,我画两张图你就明白了:
所以说,我们的多线程程序要利用锁机制,避免多个线程同时往同一区域写入数据,否则可能造成数据错乱。
那么你可能问, 既然进程和线程差不多,而且多进程数据不共享,即不存在数据错乱的问题,为什么多线程的使用比多进程普遍得多呢 ?
因为现实中数据共享的并发更普遍呀,比如十个人同时从一个账户取十元,我们希望的是这个共享账户的余额正确减少一百元,而不是希望每人获得一个账户的拷贝,每个拷贝账户减少十元。
当然,必须要说明的是, 只有 Linux 系统将线程看做共享数据的进程 ,不对其做特殊看待 ,其他的很多 *** 作系统是对线程和进程区别对待的,线程有其特有的数据结构,我个人认为不如 Linux 的这种设计简洁,增加了系统的复杂度。
在 Linux 中新建线程和进程的效率都是很高的,对于新建进程时内存区域拷贝的问题,Linux 采用了 copy-on-write 的策略优化,也就是并不真正复制父进程的内存空间,而是等到需要写 *** 作时才去复制。 所以 Linux 中新建进程和新建线程都是很迅速的 。
问题一:文件描述符和文件指针的区别 文件描述符:在linux系统中打开文件就会获得文件描述符,它是个很小的正整数。每个进程在PCB(Process Control Block)中保存着一份文件描述符表,文件描述符就是这个表的索引,每个表项都有一个指向已打开文件的指针。文件指针:C语言中使用文件指针做为I/O的句柄。文件指针指向进程用户区中的一个被称为FILE结构的数据结构。FILE结构包括一个缓冲区和一个文件描述符。而文件描述符是文件描述符表的一个索引,因此从某种意义上说文件指针就是句柄的句柄(在Windows系统上,文件描述符被称作文件句柄)。
问题二:谁能解释一下文件描述符标志? 文件描述符非负整数打现存文件或新建文件内核返文件描述符读写文件需要使用文件描述符指定待读写文件 习惯标准输入(standard input)文件描述符 0标准输(standard output) 1标准错误(standard error) 2尽管种习惯并非 Unix 内核特性些 shell 应用程序都使用种习惯内核遵循种习惯应用程序能使用 POSIX 定义 STDIN_FILENO、STDOUT_FILENO STDERR_FILENO 代替 0、1、2三符号量定义位于文件 unistd.h 文件描述符效范围 0 OPEN_MAX般说每进程打 64 文件(0 ― 63)于 FreeBSD 5.2.1、Mac OS X 10.3 Solaris 9 说每进程打文件少取决于系统内存int 及系统管理员设定限制
问题三:文件描述符的定义数量 如何在不同平台上定义文件描述符的数量文件描述符极限以及可分配给进程的最大大小由资源限制来定义。这些值应当按照在WebLogicServer文档中建议的、特定于 *** 作系统的文件描述符值来设置:对于WLS8.1:调整硬件、 *** 作系统和网络性能对于WLS7.0:调整硬件、 *** 作系统和网络性能对于WLS6.1:调整硬件、 *** 作系统和网络性能Unix和Linux都有文件描述符。不过,二者的主要区别在于如何设置文件描述符的硬极限值、缺省值和配置过程。Solaris/usr/bin/ulimit实用程序定义允许单个进程使用的文件描述符的数量。它的最大值在rlim_fd_max中定义,在缺省情况下,它设置为65,536。只有root用户才能修改这些内核值。Linux管理用户可以在etc/security/limits.conf配置文件中设置他们的文件描述符极限,如下例所示。softnofile1024hardnofile4096系统级文件描述符极限还可以通过将以下三行添加到/etc/rc.d/rc.local启动脚本中来设置:#Increasesystem-widefiledescriptorlimit.echo4096>/proc/sys/fs/file-maxecho16384>/proc/sys/fs/inode-maxWindows在Windows *** 作系统上,文件描述符被称作文件句柄。在Windows2000服务器上,打开文件的句柄极限设置为16,384。此数量可以在任务管理器的性能摘要中监视。HP-UXnfile定义打开文件的最大数量。此值通常由以下公式来确定:((NPROC*2)+1000),其中NPROC通常为:((MAXUSERS*5)+64)。如果MAXUSERS等于400,则经过计算得到此值为5128。通常可以将此值设高一些。maxfiles是每个进程的软文件极限,maxfiles_lim是每个进程的硬文件极限。AIX文件描述符极限在/etc/security/limits文件中设置,它的缺省值是2000。此极限可以通过ulimit命令或setrlimit子例程来更改。最大大小由OPEN_MAX常数来定义。
问题四:文件描述符可以是0吗 文件描述符是一个简单的整数,用以标明每一个被进程所打开的文件和socket。
第一个打开的文件是0,第二个是1,依此类推。Unix *** 作系统通常给每个进程能打开的文件数量强加一个限制。更甚的是,unix 通常有一个系统级的限制。 os.chinauni
问题五:如何判断文件描述符在fd open 一个文件将返回一个文件描述符。 0 - 返回的文件描述符 就是已经打开的。 /proc/pid/fd 下面为该进程打开的文件描述符 如果我的回答没能帮助您,请继续追问。
问题六:Linux查看进程打开多少文件描述符命令 linux系统下查看进程打开文件在/proc下,对应每个进程有一个以进程号命名的目录,该目录下有一个fd目录,该目录下面的每个文件是一个符号连接,其文件名对应该进程占用的一个文件描述符,而连接指向的内容表示文件描述符对应的实际文件,有多少个文件描述符表示该进程打开了多少文件。
另外Linux
默认的进程打开文件上限是1024个,可以通过ulimit
-n查看。很多系统上限可以通过修改/etc/security/limits.conf文件改变,这个文件有详细的注释,对如何修改做了说明。如果希望
把所有用户的进程打开文件上限改为65536,可以加入下面两行
* soft nofile 65535
* hard nofile 65535
还可以只真对某个用户或某个组做修改,具体方法参见文件注释。修改后需要重新启动系统才能生效。
问题七:linux 文件描述符 3是什么?例如 0 1 2代表标准的输出输入和出错,但是3,4又是什么的呢? 其他已经被打开的文件
问题八:文件描述符挂起是什么意思 具体 *** 作,需要修改两处,并且需重新启动Linux服务器。首先SSH登录服务器,执行ulimit-a查看当前限制。这一步是可选,主要是看下限制,心里有数。第一处修改:vim/etc/security/limits.conf在文件尾部增加:*softnofile65535*hardno
问题九:有人了解java与linux文件描述符之间的关系吗 linux文件描述符? 可以认为是linux下的任务管理中打开文件的索引表,是系统中使用的。。。。。。。java是一个平台、一种编程语言。。。。。。不知道要怎么比较了。
问题十:文件描述符fb和tcp连接数有什么关系 C10K的问题在上个世纪90年代就被提出来了。大概的意思是当用户数超过1万时,很多设计不良好的网络服务程序性能都将急剧下降、甚至瘫痪。并且,这个问题并不能通过升级硬件设备解决,是 *** 作系统固有的问题,也就是说,如果你的服务器最高能支撑1000个并发,尽管你升级了计算能力高一倍的 cpu,内存再翻一番,硬盘转速在快一倍,也无法支撑2000个并发。
经典的网络编程模型有4个:
1. Serve one client with each thread/process, and use blocking I/O。即对每个客户都使用不同的线程或进程进行服务,在每个线程或进程中使用阻塞I/O。这是小程序和java常用的策略,对于交互式的应用也是常见的选择,这种策略很能难满足高性能程序的需求,好处是实现极其简单,容易实现复杂的交互逻辑。我们常用的Apache、ftpd等都是这种工作。
2. Serve many clients with single thread, and use nonblocking I/O and readiness notification。即对所有的客户使用单一一个线程或进程进行服务,在这个线程或进程里,采用异步IO的策略。这是经典模型,优点在于实现较简单,方便移植,也能提供足够的性能;缺点在于无法充分利用多CPU的资源。
3. Serve many clients with each thread, and use nonblocking I/O and readiness notification 对经典模型2的简单改进,仍然采用异步IO的策略,但对所有的客户使用多个线程或进程进行服务。缺点是容易在多线程并发上出bug,甚至某些OS不支持多线程进行readiness notification
4. Serve many clients with each thread, and use asynchronous I/O 在有AI/O支持的OS上,能提供相当高的性能。不过AI/O编程模型和经典模型差别相当大,基本上很难写出一个框架同时支持AI/O和经典模型。这个模型主要是用于window平台上。
线程是 *** 作系统能够进行运算调度的最小单位。它被包含在进程之中,是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流,一个进程中可以并发多个线程,每条线程并行执行不同的任务。
线程是独立调度和分派的基本单位。线程可以为 *** 作系统内核调度的内核线程,如Win32线程;由用户进程自行调度的用户线程,如Linux平台的POSIX Thread;或者由内核与用户进程,如Windows 7的线程,进行混合调度。
同一进程中的多条线程将共享该进程中的全部系统资源,如虚拟地址空间,文件描述符和信号处理等等。但同一进程中的多个线程有各自的调用栈(call stack),自己的寄存器环境(register context),自己的线程本地存储(thread-local storage)。
一个进程可以有很多线程,每条线程并行执行不同的任务。
线程特点
1、轻型实体
线程中的实体基本上不拥有系统资源,只是有一点必不可少的、能保证独立运行的资源。线程的实体包括程序、数据和TCB。线程是动态概念,它的动态特性由线程控制块TCB(Thread Control Block)描述。
2、独立调度和分派的基本单位
在多线程OS中,线程是能独立运行的基本单位,因而也是独立调度和分派的基本单位。由于线程很“轻”,故线程的切换非常迅速且开销小(在同一进程中的)。
3、可并发执行
在一个进程中的多个线程之间,可以并发执行,甚至允许在一个进程中所有线程都能并发执行;同样,不同进程中的线程也能并发执行,充分利用和发挥了处理机与外围设备并行工作的能力。
4、共享进程资源
在同一进程中的各个线程,都可以共享该进程所拥有的资源,这首先表现在:所有线程都具有相同的地址空间(进程的地址空间),这意味着,线程可以访问该地址空间的每一个虚地址。
此外,还可以访问进程所拥有的已打开文件、定时器、信号量机构等。由于同一个进程内的线程共享内存和文件,所以线程之间互相通信不必调用内核。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)