一、进程和线程的概念和区别？
进程
进程依赖于程序运行而存在，进程是动态的，程序是静态的，它是操作系统进行资源分配的一个独立单位，它是具有一定独立功能的程序关于某个数据集合上的一次执行过程，是应用程序运行的载体。每个进程拥有独立的地址空间，地址空间包括代码区、数据区和堆，栈区，进程之间的地址空间是隔离的，互不影响。在Linux中，每个进程都对应一个task_struct结构体，操作系统通过调度算法选择下一个要执行的进程。
线程
是进程内部的一个实体，是CPU 调度的基本单位，它是比进程更小的能独立运行的基本单位。线程自己基本上不拥有系统资源，它只拥有一点在运行期间必不可少的资源（如程序计数器PC，一组寄存器和栈等）。但是，它可以与同属于一个进程的其他线程 共享进程所拥有的资源。
在Linux系统中，所有的执行流都被称为轻量级进程（Light weight Process，LWP），实际上就是操作系统概念中的线程。在Linux中，线程和进程的区别并不是很明显，因为Linux将线程实现为与进程相似的实体，即轻量级进程。
因此，在Linux中，CPU调度的实际执行单元是轻量级进程（线程），而不是进程。每个轻量级进程都有自己的执行流，可以独立执行代码，拥有独立的栈空间和寄存器状态。多个轻量级进程可以共享一个进程的资源，实现并发执行。
在早期的操作系统中并没有线程的概念，进程是拥有资源和独立运行的最小单位，也是程序执行的最小单位。任务调度采用的是时间片轮转的抢占式调度方式，而进程是任务调度的最小单位，每个进程有各自独立的一块内存，使得各个进程之间内存地址相互隔离。后来，随着计算机的发展，对CPU的要求越来越高，进程之间的切换开销较大，已经无法满足越来越复杂的程序的要求了。于是就发明了线程。
线程是程序执行中一个单一的顺序控制流程（即进程中的一条执行路径），是程序执行流的最小单元，是处理器调度和分派的基本单位。一个进程可以有一个或多个线程，各个线程之间共享程序的内存空间(也就是所在进程的内存空间)。一个标准的线程由线程ID，当前指令指针PC，寄存器和堆栈组成。而进程由内存空间(代码，数据，进程空间，打开的文件)和一个或多个线程组成。
进程和线程的联系
如下图进程是独立的，线程是共享进程的，他们直接的通信是有点区别的。
系统对进程管理,有一个进程控制块PCB(process control block)，是用一个结构体task_struct 描述，理论上每个进程都执向1g–4g的内存地址空间。
系统对线程管理,有一个线程控制块TCB(thread control block)，是用一个结构体 描述，每个进程都有独立的线程控制栈，用于线程切换调度，保存函数返回地址，数据状态
如下图可以看到。
共享资源：线程之间共享同一进程的资源，包括全局变量、静态变量、堆内存等。这种共享使得线程之间可以方便地进行通信和共享数据。
独立栈空间：每个线程有自己的栈空间，用于存储函数调用、局部变量等信息。线程的栈空间是独立的，但位于同一进程的地址空间中。
线程调度：Linux内核负责对线程进行调度，根据优先级、调度策略等进行线程切换。Linux支持多种调度策略，如先进先出（FIFO）、循环调度（Round-Robin）等。
线程状态：Linux线程可以处于运行、就绪、阻塞等不同状态，内核根据线程的状态来进行调度和管理。
总结：
在fork()创建的子进程中，子进程会从fork()调用的位置开始执行，继续执行父进程的代码。父进程和子进程在fork()调用之后会并发执行，
个进程有自己独立的执行流，它们可以独立地执行不同的任务或者并发执行相同的任务。
因此，子进程可以被看作是父进程的一个执行流，它继承了父进程的一部分代码和状态，但是拥有自己独立的执行环境。
但是，每次创建子进程都要复制父进程的地址空间、代码段、数据段等资源，然后将子进程的执行流独立地运行起来。这代价也不小。所以线程的优势便体现出来：创建一个新线程的代价要比创建一个新进程小得多
二、OS中用于管理控制的数据结构
在计算机系统中，对于每个资源和每个进程都设置了一个数据结构，用于表征其实体，我们称之为资源信息表或进程信息表，其中包含了资源或进程的标识、描述、状态等信息以及一批指针。通过这些指针，可以将同类资源或进程的信息表，或者同一进程所占用的资源信息表分类，链接成不同的队列，便于操作系统进行查找。
OS管理的这些数据结构一般分为以下四类：内存表、设备表、文件表和用于进程管理的进程表，通常进程表又被称为进程控制块PCB。
在 Linux 中，进程被描述成 task_struct 进行管理（PCB），而task_struct 中有个指针 struct files_struct* files，该指针负责描述该进程的文件相关数据信息
struct task_struct {
volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */
void *stack;
...
struct files_struct *files; // 负责描述进程的文件信息数据
...
}
而 struct files_struct* files 指向的结构体中有一个成员 struct file* fd_array，就是「文件描述符表」（新版本的内核版本可能称为 fdt）
完整的结构体task_struct
struct task_struct {
#ifdef CONFIG_THREAD_INFO_IN_TASK
/*
* For reasons of header soup (see current_thread_info()), this
* must be the first element of task_struct.
*/
struct thread_info thread_info;
#endif
/* -1 unrunnable, 0 runnable, >0 stopped: */
volatile long state;
/*
* This begins the randomizable portion of task_struct. Only
* scheduling-critical items should be added above here.
*/
randomized_struct_fields_start
void *stack;
refcount_t usage;
/* Per task flags (PF_*), defined further below: */
unsigned int flags;
unsigned int ptrace;
#ifdef CONFIG_SMP
struct llist_node wake_entry;
int on_cpu;
#ifdef CONFIG_THREAD_INFO_IN_TASK
/* Current CPU: */
unsigned int cpu;
#endif
unsigned int wakee_flips;
unsigned long wakee_flip_decay_ts;
struct task_struct *last_wakee;
/*
* recent_used_cpu is initially set as the last CPU used by a task
* that wakes affine another task. Waker/wakee relationships can
* push tasks around a CPU where each wakeup moves to the next one.
* Tracking a recently used CPU allows a quick search for a recently
* used CPU that may be idle.
*/
int recent_used_cpu;
int wake_cpu;
#endif
int on_rq;
int prio;
int static_prio;
int normal_prio;
unsigned int rt_priority;
const struct sched_class *sched_class;
struct sched_entity se;
struct sched_rt_entity rt;
#ifdef CONFIG_CGROUP_SCHED
struct task_group *sched_task_group;
#endif
struct sched_dl_entity dl;
#ifdef CONFIG_UCLAMP_TASK
/* Clamp values requested for a scheduling entity */
struct uclamp_se uclamp_req[UCLAMP_CNT];
/* Effective clamp values used for a scheduling entity */
struct uclamp_se uclamp[UCLAMP_CNT];
#endif
#ifdef CONFIG_PREEMPT_NOTIFIERS
/* List of struct preempt_notifier: */
struct hlist_head preempt_notifiers;
#endif
#ifdef CONFIG_BLK_DEV_IO_TRACE
unsigned int btrace_seq;
#endif
unsigned int policy;
int nr_cpus_allowed;
const cpumask_t *cpus_ptr;
cpumask_t cpus_mask;
#ifdef CONFIG_PREEMPT_RCU
int rcu_read_lock_nesting;
union rcu_special rcu_read_unlock_special;
struct list_head rcu_node_entry;
struct rcu_node *rcu_blocked_node;
#endif /* #ifdef CONFIG_PREEMPT_RCU */
#ifdef CONFIG_TASKS_RCU
unsigned long rcu_tasks_nvcsw;
u8 rcu_tasks_holdout;
u8 rcu_tasks_idx;
int rcu_tasks_idle_cpu;
struct list_head rcu_tasks_holdout_list;
#endif /* #ifdef CONFIG_TASKS_RCU */
struct sched_info sched_info;
struct list_head tasks;
#ifdef CONFIG_SMP
struct plist_node pushable_tasks;
struct rb_node pushable_dl_tasks;
#endif
struct mm_struct *mm;
struct mm_struct *active_mm;
/* Per-thread vma caching: */
struct vmacache vmacache;
#ifdef SPLIT_RSS_COUNTING
struct task_rss_stat rss_stat;
#endif
int exit_state;
int exit_code;
int exit_signal;
/* The signal sent when the parent dies: */
int pdeath_signal;
/* JOBCTL_*, siglock protected: */
unsigned long jobctl;
/* Used for emulating ABI behavior of previous Linux versions: */
unsigned int personality;
/* Scheduler bits, serialized by scheduler locks: */
unsigned sched_reset_on_fork:1;
unsigned sched_contributes_to_load:1;
unsigned sched_migrated:1;
unsigned sched_remote_wakeup:1;
#ifdef CONFIG_PSI
unsigned sched_psi_wake_requeue:1;
#endif
/* Force alignment to the next boundary: */
unsigned :0;
/* Unserialized, strictly 'current' */
/* Bit to tell LSMs we're in execve(): */
unsigned in_execve:1;
unsigned in_iowait:1;
#ifndef TIF_RESTORE_SIGMASK
unsigned restore_sigmask:1;
#endif
#ifdef CONFIG_MEMCG
unsigned in_user_fault:1;
#endif
#ifdef CONFIG_COMPAT_BRK
unsigned brk_randomized:1;
#endif
#ifdef CONFIG_CGROUPS
/* disallow userland-initiated cgroup migration */
unsigned no_cgroup_migration:1;
/* task is frozen/stopped (used by the cgroup freezer) */
unsigned frozen:1;
#endif
#ifdef CONFIG_BLK_CGROUP
/* to be used once the psi infrastructure lands upstream. */
unsigned use_memdelay:1;
#endif
unsigned long atomic_flags; /* Flags requiring atomic access. */
struct restart_block restart_block;
pid_t pid;
pid_t tgid;
#ifdef CONFIG_STACKPROTECTOR
/* Canary value for the -fstack-protector GCC feature: */
unsigned long stack_canary;
#endif
/*
* Pointers to the (original) parent process, youngest child, younger sibling,
* older sibling, respectively. (p->father can be replaced with
* p->real_parent->pid)
*/
/* Real parent process: */
struct task_struct __rcu *real_parent;
/* Recipient of SIGCHLD, wait4() reports: */
struct task_struct __rcu *parent;
/*
* Children/sibling form the list of natural children:
*/
struct list_head children;
struct list_head sibling;
struct task_struct *group_leader;
/*
* 'ptraced' is the list of tasks this task is using ptrace() on.
*
* This includes both natural children and PTRACE_ATTACH targets.
* 'ptrace_entry' is this task's link on the p->parent->ptraced list.
*/
struct list_head ptraced;
struct list_head ptrace_entry;
/* PID/PID hash table linkage. */
struct pid *thread_pid;
struct hlist_node pid_links[PIDTYPE_MAX];
struct list_head thread_group;
struct list_head thread_node;
struct completion *vfork_done;
/* CLONE_CHILD_SETTID: */
int __user *set_child_tid;
/* CLONE_CHILD_CLEARTID: */
int __user *clear_child_tid;
u64 utime;
u64 stime;
#ifdef CONFIG_ARCH_HAS_SCALED_CPUTIME
u64 utimescaled;
u64 stimescaled;
#endif
u64 gtime;
struct prev_cputime prev_cputime;
#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
struct vtime vtime;
#endif
#ifdef CONFIG_NO_HZ_FULL
atomic_t tick_dep_mask;
#endif
/* Context switch counts: */
unsigned long nvcsw;
unsigned long nivcsw;
/* Monotonic time in nsecs: */
u64 start_time;
/* Boot based time in nsecs: */
u64 start_boottime;
/* MM fault and swap info: this can arguably be seen as either mm-specific or thread-specific: */
unsigned long min_flt;
unsigned long maj_flt;
/* Empty if CONFIG_POSIX_CPUTIMERS=n */
struct posix_cputimers posix_cputimers;
/* Process credentials: */
/* Tracer's credentials at attach: */
const struct cred __rcu *ptracer_cred;
/* Objective and real subjective task credentials (COW): */
const struct cred __rcu *real_cred;
/* Effective (overridable) subjective task credentials (COW): */
const struct cred __rcu *cred;
#ifdef CONFIG_KEYS
/* Cached requested key. */
struct key *cached_requested_key;
#endif
/*
* executable name, excluding path.
*
* - normally initialized setup_new_exec()
* - access it with [gs]et_task_comm()
* - lock it with task_lock()
*/
char comm[TASK_COMM_LEN];
struct nameidata *nameidata;
#ifdef CONFIG_SYSVIPC
struct sysv_sem sysvsem;
struct sysv_shm sysvshm;
#endif
#ifdef CONFIG_DETECT_HUNG_TASK
unsigned long last_switch_count;
unsigned long last_switch_time;
#endif
/* Filesystem information: */
struct fs_struct *fs;
/* Open file information: */
struct files_struct *files;
/* Namespaces: */
struct nsproxy *nsproxy;
/* Signal handlers: */
struct signal_struct *signal;
struct sighand_struct __rcu *sighand;
sigset_t blocked;
sigset_t real_blocked;
/* Restored if set_restore_sigmask() was used: */
sigset_t saved_sigmask;
struct sigpending pending;
unsigned long sas_ss_sp;
size_t sas_ss_size;
unsigned int sas_ss_flags;
struct callback_head *task_works;
#ifdef CONFIG_AUDIT
#ifdef CONFIG_AUDITSYSCALL
struct audit_context *audit_context;
#endif
kuid_t loginuid;
unsigned int sessionid;
#endif
struct seccomp seccomp;
/* Thread group tracking: */
u64 parent_exec_id;
u64 self_exec_id;
/* Protection against (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed, mempolicy: */
spinlock_t alloc_lock;
/* Protection of the PI data structures: */
raw_spinlock_t pi_lock;
struct wake_q_node wake_q;
#ifdef CONFIG_RT_MUTEXES
/* PI waiters blocked on a rt_mutex held by this task: */
struct rb_root_cached pi_waiters;
/* Updated under owner's pi_lock and rq lock */
struct task_struct *pi_top_task;
/* Deadlock detection and priority inheritance handling: */
struct rt_mutex_waiter *pi_blocked_on;
#endif
#ifdef CONFIG_DEBUG_MUTEXES
/* Mutex deadlock detection: */
struct mutex_waiter *blocked_on;
#endif
#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
int non_block_count;
#endif
#ifdef CONFIG_TRACE_IRQFLAGS
unsigned int irq_events;
unsigned long hardirq_enable_ip;
unsigned long hardirq_disable_ip;
unsigned int hardirq_enable_event;
unsigned int hardirq_disable_event;
int hardirqs_enabled;
int hardirq_context;
unsigned long softirq_disable_ip;
unsigned long softirq_enable_ip;
unsigned int softirq_disable_event;
unsigned int softirq_enable_event;
int softirqs_enabled;
int softirq_context;
#endif
#ifdef CONFIG_LOCKDEP
# define MAX_LOCK_DEPTH 48UL
u64 curr_chain_key;
int lockdep_depth;
unsigned int lockdep_recursion;
struct held_lock held_locks[MAX_LOCK_DEPTH];
#endif
#ifdef CONFIG_UBSAN
unsigned int in_ubsan;
#endif
/* Journalling filesystem info: */
void *journal_info;
/* Stacked block device info: */
struct bio_list *bio_list;
#ifdef CONFIG_BLOCK
/* Stack plugging: */
struct blk_plug *plug;
#endif
/* VM state: */
struct reclaim_state *reclaim_state;
struct backing_dev_info *backing_dev_info;
struct io_context *io_context;
#ifdef CONFIG_COMPACTION
struct capture_control *capture_control;
#endif
/* Ptrace state: */
unsigned long ptrace_message;
kernel_siginfo_t *last_siginfo;
struct task_io_accounting ioac;
#ifdef CONFIG_PSI
/* Pressure stall state */
unsigned int psi_flags;
#endif
#ifdef CONFIG_TASK_XACCT
/* Accumulated RSS usage: */
u64 acct_rss_mem1;
/* Accumulated virtual memory usage: */
u64 acct_vm_mem1;
/* stime + utime since last update: */
u64 acct_timexpd;
#endif
#ifdef CONFIG_CPUSETS
/* Protected by ->alloc_lock: */
nodemask_t mems_allowed;
/* Seqence number to catch updates: */
seqcount_t mems_allowed_seq;
int cpuset_mem_spread_rotor;
int cpuset_slab_spread_rotor;
#endif
#ifdef CONFIG_CGROUPS
/* Control Group info protected by css_set_lock: */
struct css_set __rcu *cgroups;
/* cg_list protected by css_set_lock and tsk->alloc_lock: */
struct list_head cg_list;
#endif
#ifdef CONFIG_X86_CPU_RESCTRL
u32 closid;
u32 rmid;
#endif
#ifdef CONFIG_FUTEX
struct robust_list_head __user *robust_list;
#ifdef CONFIG_COMPAT
struct compat_robust_list_head __user *compat_robust_list;
#endif
struct list_head pi_state_list;
struct futex_pi_state *pi_state_cache;
struct mutex futex_exit_mutex;
unsigned int futex_state;
#endif
#ifdef CONFIG_PERF_EVENTS
struct perf_event_context *perf_event_ctxp[perf_nr_task_contexts];
struct mutex perf_event_mutex;
struct list_head perf_event_list;
#endif
#ifdef CONFIG_DEBUG_PREEMPT
unsigned long preempt_disable_ip;
#endif
#ifdef CONFIG_NUMA
/* Protected by alloc_lock: */
struct mempolicy *mempolicy;
short il_prev;
short pref_node_fork;
#endif
#ifdef CONFIG_NUMA_BALANCING
int numa_scan_seq;
unsigned int numa_scan_period;
unsigned int numa_scan_period_max;
int numa_preferred_nid;
unsigned long numa_migrate_retry;
/* Migration stamp: */
u64 node_stamp;
u64 last_task_numa_placement;
u64 last_sum_exec_runtime;
struct callback_head numa_work;
/*
* This pointer is only modified for current in syscall and
* pagefault context (and for tasks being destroyed), so it can be read
* from any of the following contexts:
* - RCU read-side critical section
* - current->numa_group from everywhere
* - task's runqueue locked, task not running
*/
struct numa_group __rcu *numa_group;
/*
* numa_faults is an array split into four regions:
* faults_memory, faults_cpu, faults_memory_buffer, faults_cpu_buffer
* in this precise order.
*
* faults_memory: Exponential decaying average of faults on a per-node
* basis. Scheduling placement decisions are made based on these
* counts. The values remain static for the duration of a PTE scan.
* faults_cpu: Track the nodes the process was running on when a NUMA
* hinting fault was incurred.
* faults_memory_buffer and faults_cpu_buffer: Record faults per node
* during the current scan window. When the scan completes, the counts
* in faults_memory and faults_cpu decay and these values are copied.
*/
unsigned long *numa_faults;
unsigned long total_numa_faults;
/*
* numa_faults_locality tracks if faults recorded during the last
* scan window were remote/local or failed to migrate. The task scan
* period is adapted based on the locality of the faults with different
* weights depending on whether they were shared or private faults
*/
unsigned long numa_faults_locality[3];
unsigned long numa_pages_migrated;
#endif /* CONFIG_NUMA_BALANCING */
#ifdef CONFIG_RSEQ
struct rseq __user *rseq;
u32 rseq_sig;
/*
* RmW on rseq_event_mask must be performed atomically
* with respect to preemption.
*/
unsigned long rseq_event_mask;
#endif
struct tlbflush_unmap_batch tlb_ubc;
union {
refcount_t rcu_users;
struct rcu_head rcu;
};
/* Cache last used pipe for splice(): */
struct pipe_inode_info *splice_pipe;
struct page_frag task_frag;
#ifdef CONFIG_TASK_DELAY_ACCT
struct task_delay_info *delays;
#endif
#ifdef CONFIG_FAULT_INJECTION
int make_it_fail;
unsigned int fail_nth;
#endif
/*
* When (nr_dirtied >= nr_dirtied_pause), it's time to call
* balance_dirty_pages() for a dirty throttling pause:
*/
int nr_dirtied;
int nr_dirtied_pause;
/* Start of a write-and-pause period: */
unsigned long dirty_paused_when;
#ifdef CONFIG_LATENCYTOP
int latency_record_count;
struct latency_record latency_record[LT_SAVECOUNT];
#endif
/*
* Time slack values; these are used to round up poll() and
* select() etc timeout values. These are in nanoseconds.
*/
u64 timer_slack_ns;
u64 default_timer_slack_ns;
#ifdef CONFIG_KASAN
unsigned int kasan_depth;
#endif
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
/* Index of current stored address in ret_stack: */
int curr_ret_stack;
int curr_ret_depth;
/* Stack of return addresses for return function tracing: */
struct ftrace_ret_stack *ret_stack;
/* Timestamp for last schedule: */
unsigned long long ftrace_timestamp;
/*
* Number of functions that haven't been traced
* because of depth overrun:
*/
atomic_t trace_overrun;
/* Pause tracing: */
atomic_t tracing_graph_pause;
#endif
#ifdef CONFIG_TRACING
/* State flags for use by tracers: */
unsigned long trace;
/* Bitmask and counter of trace recursion: */
unsigned long trace_recursion;
#endif /* CONFIG_TRACING */
#ifdef CONFIG_KCOV
/* See kernel/kcov.c for more details. */
/* Coverage collection mode enabled for this task (0 if disabled): */
unsigned int kcov_mode;
/* Size of the kcov_area: */
unsigned int kcov_size;
/* Buffer for coverage collection: */
void *kcov_area;
/* KCOV descriptor wired with this task or NULL: */
struct kcov *kcov;
/* KCOV common handle for remote coverage collection: */
u64 kcov_handle;
/* KCOV sequence number: */
int kcov_sequence;
#endif
#ifdef CONFIG_MEMCG
struct mem_cgroup *memcg_in_oom;
gfp_t memcg_oom_gfp_mask;
int memcg_oom_order;
/* Number of pages to reclaim on returning to userland: */
unsigned int memcg_nr_pages_over_high;
/* Used by memcontrol for targeted memcg charge: */
struct mem_cgroup *active_memcg;
#endif
#ifdef CONFIG_BLK_CGROUP
struct request_queue *throttle_queue;
#endif
#ifdef CONFIG_UPROBES
struct uprobe_task *utask;
#endif
#if defined(CONFIG_BCACHE) || defined(CONFIG_BCACHE_MODULE)
unsigned int sequential_io;
unsigned int sequential_io_avg;
#endif
#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
unsigned long task_state_change;
#endif
int pagefault_disabled;
#ifdef CONFIG_MMU
struct task_struct *oom_reaper_list;
#endif
#ifdef CONFIG_VMAP_STACK
struct vm_struct *stack_vm_area;
#endif
#ifdef CONFIG_THREAD_INFO_IN_TASK
/* A live task holds one reference: */
refcount_t stack_refcount;
#endif
#ifdef CONFIG_LIVEPATCH
int patch_state;
#endif
#ifdef CONFIG_SECURITY
/* Used by LSM modules for access restriction: */
void *security;
#endif
#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
unsigned long lowest_stack;
unsigned long prev_lowest_stack;
#endif
/*
* New fields for task_struct should be added above here, so that
* they are included in the randomized portion of task_struct.
*/
randomized_struct_fields_end
/* CPU-specific state of this task: */
struct thread_struct thread;
/*
* WARNING: on x86, 'thread_struct' contains a variable-sized
* structure. It *MUST* be at the end of 'task_struct'.
*
* Do not put anything below here!
*/
};
可以看到进程管理结构体非常庞大，如果进程切换，需要保存的数据很大的。
进程控制块PCB的作用
(1) 作为独立运行基本单位的标志。
(2) 能实现间断性运行方式。
(3) 提供进程管理所需要的信息。
(4) 提供进程调度所需要的信息。
(5) 实现与其它进程的同步与通信。
进程控制块中的信息
在进程控制块中主要包括四部分的信息：
1）进程标识符
进程标识符用于唯一地标识一个进程。一个进程通常有两种标识符：
a) 外部标识符（相当于是可执行程序的文件名，由创建者提供，通常是由字母、数字组成，往往是用户访问该进程使用，自己编译后起的名字）。
b) 内部标识符（方便系统使用而设置,每一个进程赋予一个唯一的整数，作为内部标识符，**PID**）。
2) 处理机状态
处理机状态信息也称为处理机的上下文，主要是由处理机的各种寄存器中的内容组成的。
3）进程调度信息
在OS进行调度时，必须了解进程的状态及有关进程调度的信息，这些信息包括：
① 进程状态，指明进程的当前状态，它是作为进程调度和对换时的依据；
② 进程优先级，是用于描述进程使用处理机的优先级别的一个整数，优先级高的进程应优先获得处理机；
③ 进程调度所需的其它信息，它们与所采用的进程调度算法有关，比如，进程已等待CPU的时间总和、进程已执行的时间总和等；
④ 事件，是指进程由执行状态转变为阻塞状态所等待发生的事件，即阻塞原因。
4）进程控制信息
是指用于进程控制所必须的信息，它包括：
① 程序和数据的地址，进程实体中的程序和数据的内存或外存地(首)址，以便再调度到该进程执行时，能从PCB中找到其程序和数据；
② 进程同步和通信机制，这是实现进程同步和进程通信时必需的机制，如消息队列指针、信号量等，它们可能全部或部分地放在PCB中；
③ 资源清单，在该清单中列出了进程在运行期间所需的全部资源(除CPU以外)，另外还有一张已分配到该进程的资源的清单；
④ 链接指针，它给出了本进程(PCB)所在队列中的下一个进程的PCB的首地址。
三、区别
进程和线程的主要差别在于，它们是不同的操作系统资源管理方式。
进程具有独立的地址空间，一个进程崩溃后，在保护模式下不会对其它进程产生影响。
而线程，它只是一个进程内部的不同代码执行流。线程有自己的栈空间（存储局部变量），但是，线程之间没有单独的地址空间，一个线程死掉就等于整个进程死掉。
所以，多进程的程序要比多线程的程序更健壮。但是在不同的进程之间切换时，耗费资源较大，效率要差一些。
对于一些要求同时执行并且又要共享某些变量的并发操作，只能用线程，不能用进程。
1）简而言之，一个程序至少有一个进程，一个进程至少有一个线程。
2）线程的划分尺度小于进程，使得多线程程序的并发性高。
3）另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。
4）线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。
5）从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。
一个线程可以创建和撤销另一个线程。同一个进程内部的多个线程之间可以并发执行。
相对进程而言，线程是一个更加接近于代码执行体的概念，它可以与同进程中的其他线程共享数据，但拥有自己独立的栈空间，拥有独立的执行序列。
进程的创建、销毁与切换存在着较大的时空开销，因此人们急需一种轻型的进程技术来减少开销。在80年代，线程的概念开始出现，线程被设计成进程的一个执行路径，同一个进程中的线程共享进程的资源，因此系统对线程的调度所需的成本远远小于进程。
(1).进程是系统资源分配的基本单位，线程是cpu调度执行的基本单位。一个进程中包含多条线程。
(2).多进程中，进程之间的资源都是独立的，同一进程中的多份线程资源共享。
(3).线程更加轻便小巧，从而使线程调度、切换都比线程效率高。进程切换效率低，代价大；线程切换效率高，代价小
(4).进程
**共享：**代码段、公共数据、进程目录、进程ID
**私有：**地址空间、堆、栈、全局变量、寄存器
(5)线程
**共享：**堆、地址空间、全局变量、静态变量
**私有：**线程栈、寄存器、程序寄存器
(6).多进程之间资源不共享的，只有父子进程共享在fork()之前打开的文件描述符；多线程之间资源共享，只有栈区不共享
为什么要使用多线程？
在一个程序中，有很多的操作是非常耗时的，如数据库读写操作，IO操作等，如果使用单线程，那么程序就必须等待这些操作执行完成之后才能执行其他操作。使用多线程，可以在将耗时任务放在后台继续执行的同时，同时执行其他操作。可以提高程序的效率。
在一些等待的任务上，如用户输入，文件读取等，多线程就非常有用了。
多线程的缺点：
使用太多线程，是很耗系统资源，因为线程需要开辟内存。更多线程需要更多内存。
影响系统性能，因为操作系统需要在线程之间来回切换。
需要考虑线程操作对程序的影响，如线程挂起，中止等操作对程序的影响。
线程使用不当会发生很多问题。
总结：多线程是异步的，但这不代表多线程真的是几个线程是在同时进行，实际上是系统不断地在各个线程之间来回的切换（因为系统切换的速度非常的快，所以给我们在同时运行的错觉）。
理论过于抽象难解，下面还是用大家喜闻乐见的现实中的例子去类比，没错还是工厂的例子：
在计算机，有很多个进程，进程1,2,3 。这个大工厂中，进程被比作一个车间，为生产活动提供了设计图、场地、生产线（线程），生产线共享的生产原材料，等生产要素。
一个工厂，有多个车间，每一个车间，负责不同的任务，车间1，负责初步加工，车间2，负责精加工，车间3，负责组装出货。形成流水线，相互等待，假设这个工厂，只有100个人，资源有限，而要负责三个车间的生产任务，每次只能去一个生产车间，从1切换到2，2切换到3，然后又切回车间1。这个过程称为进程上下文切换。
而线程是这个车间中的一条条生产线。生产线本身会有一个操作台，具体的零件在这里被生产。然而仍然是只有这么些人，资源有限，一次只能去产线1，然后切换到产线2，再切换到产线3,，过程称为线程上下文切换。
工人在多个车间，多条生产线间穿梭操作，看起来是把所有事都干了，来回切换。回到计算机中，假设是单核cpu，只有一个cpu，资源有限，那就需要来回切换，就像CPU在不同进程，线程间切换一样，这个动作被称为并发。当然这是假并发，微观上，他们是串行。宏观上是并发。
四、并行与并发
一个基本的事实前提：单核CPU在一个瞬间只能处理一个任务，就像人只有一张嘴，不能吃饭的同时，又说话，又唱歌，有人抬杠，不是同时进行的吗，说话时声带振动，吃饭吞咽时，是不可以声带振动的，不然会被噎死。但为什么在我们人类视角，哪怕是单核心计算机也能同时做很多事情，比如同时听音乐和浏览网页，作为整个系统唯一可以完成计算任务的 CPU 是如何保证两个进程“同时进行”的呢？时间片轮转调度！
每个进程会被操作系统分配一个时间片，即每次被 CPU 选中来执行当前进程所用的时间。时间一到，无论进程是否运行结束，操作系统都会强制将 CPU 这个资源转到另一个进程去执行。为什么要这样做呢？因为只有一个单核 CPU，假如没有这种轮转调度机制，那它该去处理写文档的进程还是该去处理听音乐的进程？无论执行哪个进程，另一个进程肯定是不被执行，程序自然就是无运行的状态。如果 CPU 一会儿处理 word 进程一会儿处理听音乐的进程，起初看起来好像会觉得两个进程都很卡，但是 CPU 的执行速度已经快到让人们感觉不到这种切换的顿挫感，就真的好像两个进程在“并行运行”。
随着多核心CPU的出现，真正的并行得以实现，那就可以多个进程，同时进行调度，线程同时被调度，大大提高了运行效率。这就是多进程，多线程的并行
所谓的进程上下文，就是一个进程在执行的时候，CPU的所有寄存器中的值、进程的状态以及堆栈上的内容，当内核需要切换到另一个进程时，它 需要保存当前进程的所有状态，即保存当前进程的进程上下文，以便再次执行该进程时，能够恢复切换时的状态，继续执行。
5 线程共享了进程哪些资源
“进程是操作系统分配资源的单位，线程是调度的基本单位，线程之间共享进程资源”。
可是你真的理解了上面的那句话吗？到底线程之间共享了哪些进程资源，共享资源意味着什么？共享资源这种机制是如何实现的？
线程私有资源
函数运行时的信息保存在栈帧中，栈帧中保存了函数的返回值、调用其它函数的参数、该函数使用的局部变量以及该函数使用的寄存器信息，如图所示，假设函数A调用函数B：
此外，CPU 执行指令的信息保存在一个叫做程序计数器的寄存器中，通过这个寄存器我们就知道接下来要执行哪一条指令。由于操作系统随时可以暂停线程的运行，因此我们保存以及恢复程序计数器中的值就能知道线程是从哪里暂停的以及该从哪里继续运行了。
由于线程运行的本质就是函数运行，函数运行时信息是保存在栈帧中的，因此每个线程都有自己独立的、私有的栈区。
同时函数运行时需要额外的寄存器来保存一些信息，像部分局部变量之类。这些寄存器也是线程私有的，一个线程不可能访问到另一个线程的这类寄存器信息。
从上面的讨论中我们知道，到目前为止，所属线程的栈区、程序计数器、栈指针以及函数运行使用的寄存器是线程私有的。
以上这些信息有一个统一的名字，就是线程上下文，thread context。
我们也说过操作系统调度线程需要随时中断线程的运行并且需要线程被暂停后可以继续运行，操作系统之所以能实现这一点，依靠的就是线程上下文信息。
现在你应该知道哪些是线程私有的了吧。除此之外，剩下的都是线程间共享资源。那么剩下的还有什么呢？还有图中的这些。
这其实就是进程地址空间的样子，也就是说线程共享进程地址空间中除线程上下文信息中的所有内容，意思就是说线程可以直接读取这些内容。
代码区
进程地址空间中的代码区，这里保存的是什么呢？从名字中有的同学可能已经猜到了，没错，这里保存的就是我们写的代码，更准确的是编译后的可执行机器指令。
那么这些机器指令又是从哪里来的呢？答案是从可执行文件中加载到内存的，可执行程序中的代码区就是用来初始化进程地址空间中的代码区的。
线程之间共享代码区，这就意味着程序中的任何一个函数都可以放到线程中去执行，不存在某个函数只能被特定线程执行的情况。
数据区
进程地址空间中的数据区，这里存放的就是所谓的全局变量。
什么是全局变量？所谓全局变量就是那些你定义在函数之外的变量，在 C 语言中就像这样：
堆区
堆区是程序员比较熟悉的，我们在 C/C++中用 malloc 或者 new 出来的数据就存放在这个区域，很显然，只要知道变量的地址，也就是指针，任何一个线程都可以访问指针指向的数据，因此堆区也是线程共享的属于进程的资源。
六、进程的三种基本状态
由于多个进程在并发执行时共享系统资源，致使它们在运行过程中呈现间断性的运行规律，所以进程在其生命周期内可能具有多种状态。一般而言，每一个进程至少应处于以下三种基本状态之一：(1) 就绪(Ready)状态。
(2) 执行(Running)状态。
(3) 阻塞(Block)状态。
进程的三种状态之间的转换
进程在运行过程中会经常发生状态的转换。例如，处于就绪状态的进程，在调度程序为之分配了处理机之后便可执行，相应地，其状态就由就绪态转变为执行态；正在执行的进程(当前进程)如果因分配给它的时间片已完而被剥夺处理机暂停执行时，其状态便由执行转为就绪；如果因发生某事件，致使当前进程的执行受阻(例如进程访问某临界资源，而该资源正被其它进程访问时)，使之无法继续执行，则该进程状态将由执行转变为阻塞。图2-5示出了进程的三种基本状态，以及各状态之间的转换关系。
进程的创建状态
进程是由创建而产生。创建一个进程是个很复杂的过程，一般要通过多个步骤才能完成：如首先由进程申请一个空白PCB，并向PCB中填写用于控制和管理进程的信息；然后为该进程分配运行时所必须的资源；最后，把该进程转入就绪状态并插入就绪队列之中。但如果进程所需的资源尚不能得到满足，比如系统尚无足够的内存使进程无法装入其中，此时创建工作尚未完成，进程不能被调度运行，于是把此时进程所处的状态称为创建状态。
进程的终止状态
进程的终止也要通过两个步骤：首先，是等待操作系统进行善后处理，最后将其PCB清零，并将PCB空间返还系统。当一个进程到达了自然结束点，或是出现了无法克服的错误，或是被操作系统所终结，或是被其他有终止权的进程所终结，它将进入终止状态。进入终止态的进程以后不能再执行，但在操作系统中依然保留一个记录，其中保存状态码和一些计时统计数据，供其他进程收集。一旦其他进程完成了对其信息的提取之后，操作系统将删除该进程，即将其PCB清零，并将该空白PCB返还系统。
七态模型描述
进程的挂起
到目前为止，我们或多或少总是假设所有的进程都在内存中。事实上，可能出现这样一些情况，例如由于进程的不断创建，系统的资源已经不能满足进程运行的要求，这个时候就必须把某些进程挂起（suspend），对换到磁盘镜像区中，暂时不参与进程调度，起到平滑系统操作负荷的目的。
引起进程挂起的原因是多样的，主要有：
- 系统中的进程均处于等待状态，处理器空闲，此时需要把一些阻塞进程对换出去，以腾出足够的内存装入就绪进程运行。
- 进程竞争资源，导致系统资源不足，负荷过重，此时需要挂起部分进程以调整系统负荷 ,保证系统的实时性或让系统正常运行。
- 把一些定期执行的进程（如审计程序、监控程序、记账程序）对换出去，以减轻系统负荷。
- 用户要求挂起自己的进程，以便根据中间执行情况和中间结果进行某些调试、检查和改正。
- 父进程要求挂起自己的后代进程，以进行某些检查和改正。
- 操作系统需要挂起某些进程，检查运行中资源使用情况，以改善系统性能;或当系统出现故障或某些功能受到破坏时，需要挂起某些进程以排除故障。
下面是具有七态模型的进程状态及其转换：
总结：
提问 工作线程数是不是设置的越大越好？
回答：不是的。
1）服务器的CPU核数 有限，同时并发的线程数也是有限的，1核CPU设置10000个工作线程没有意义。
2）线程之间的切换是有开销的，如果线程切换过于频繁，反而会使性能降低。
提问：调用sleep() 函数的时候，线程是否一直占用CPU？
回答：不占用，调用sleep() 等待时会把CPU 让出来，给其他需要CPU 资源的线程使用。
不止调用sleep() 函数，在进行一些阻塞调用，例如网络编程中的阻塞 accept()【等待客户端连接】和 阻塞
recv()【等待下游回包】也不占用CPU资源。
提问：如果CPU是单核，设置多线程有意义么，能提高并发性能么？
回答：即使是单核，使用多线程也是有意义的。
1）多线程编码可以让我们的服务/代码更加清晰：有些IO线程收发包，有些Worker线程进行任务处理，有些Timeout线程进行超时检测。
2）如果有一个任务一直占用CPU资源在进行计算，那么此时增加线程并不能增加并发。
例如这样的一个代码：
while(1) { i++; }
该代码一直不停的占用CPU资源进行计算，会使CPU占用率达到100%。
3）通常来说，Worker线程一般不会一直占用CPU进行计算，此时即使CPU是单核，增加Worker线程也能够提高并发，因为这个线程在休息的时候，其他的线程可以继续工作。
五、进程之间通信的方式有哪些？线程之间通信的方式有哪些？
7 种进程间的通信方式：
（1） 管道（pipe）：管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有血缘关系的进程间使用。进程的血缘关系通常指父子进程关系。
（2）有名管道（named pipe）：有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间通信。
（3）信号量（semophore）：信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它通常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
（4）消息队列（message queue）：消息队列是由消息组成的链表，存放在内核中 并由消息队列标识符标识。消息队列克服了信号传递信息少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。
（5）信号处理机制（signal）：信号是一种比较复杂的通信方式，用于通知接收进程某一事件已经发生。
（6）共享内存（shared memory）：共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问，共享内存是最快的IPC方式，它是针对其他进程间的通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号量配合使用，来实现进程间的同步和通信。
（7）套接字（socket）：套接字也是一种进程间的通信机制，与其他通信机制不同的是它可以用于不同及其间的进程通信。
3种 线程间的通信机制：
（1）锁机制：
1.1 互斥锁 mutex：提供了以排它方式阻止数据结构被并发修改的方法。
1.2 读写锁 read/write：允许多个线程同时读共享数据，而对写操作互斥。
1.3 条件变量 condtion variable：可以以原子的方式阻塞进程，直到某个特定条件为真为止。对条件测试是在互斥锁mutex 的保护下进行的。条件变量始终与互斥锁一起使用。
（2）信号量机制：比如常用的二进制信号量0和1。
（3）信号处理器机制：类似于进程间的信号处理。
扫一扫
3399
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
