首先查看系统资源的消耗情况
top 资源负载不高
检查VS CODE的进程信息
ps -aux | grep code
打开了很多的进程，可以通过pid ppid观察进程间的父子关系。
查看VS CODE某个进程的详细信息
cat /proc/pid/status
Name 应用程序或命令的名字
State 任务的状态，运行/睡眠/僵死/
SleepAVG 任务的平均等待时间(以nanosecond为单位)，交互式任务因为休眠次数多、时间长，它们的 sleep_avg 也会相应地更大一些，所以计算出来的优先级也会相应高一些。
Tgid 线程组号
Pid 任务ID
Ppid 父进程ID
TracerPid 接收跟踪该进程信息的进程的ID号
Uid Uid euid suid fsuid
Gid Gid egid sgid fsgid
FDSize 文件描述符的最大个数，file->fds
Groups
VmSize(KB) 任务虚拟地址空间的大小 (total_vm-reserved_vm)，其中total_vm为进程的地址空间的大小，reserved_vm：进程在预留或特殊的内存间的物理页
VmLck(KB) 任务已经锁住的物理内存的大小。锁住的物理内存不能交换到硬盘 (locked_vm)
VmRSS(KB) 应用程序正在使用的物理内存的大小，就是用ps命令的参数rss的值 (rss)
VmData(KB) 程序数据段的大小（所占虚拟内存的大小），存放初始化了的数据； (total_vm-shared_vm-stack_vm)
VmStk(KB) 任务在用户态的栈的大小 (stack_vm)
VmExe(KB) 程序所拥有的可执行虚拟内存的大小，代码段，不包括任务使用的库 (end_code-start_code)
VmLib(KB) 被映像到任务的虚拟内存空间的库的大小 (exec_lib)
VmPTE 该进程的所有页表的大小，单位：kb
Threads 共享使用该信号描述符的任务的个数，在POSIX多线程序应用程序中，线程组中的所有线程使用同一个信号描述符。
SigQ 待处理信号的个数
SigPnd 屏蔽位，存储了该线程的待处理信号
ShdPnd 屏蔽位，存储了该线程组的待处理信号
SigBlk 存放被阻塞的信号
SigIgn 存放被忽略的信号
SigCgt 存放被俘获到的信号
CapInh Inheritable，能被当前进程执行的程序的继承的能力
CapPrm Permitted，进程能够使用的能力，可以包含CapEff中没有的能力，这些能力是被进程自己临时放弃的，CapEff是CapPrm的一个子集，进程放弃没有必要的能力有利于提高安全性
CapEff Effective，进程的有效能力
查看vs code的日志
vs code的打开后，会在当前用户的家目录下的.config目录中创建自己的用户相关的一些配置，其中日志也在该目录。各种软件皆是如此，如果软件出现打不开的问题，可能是该目录下的内容被破坏，可以尝试删除该目录，基本上问题都能得到解决（一次Chrome打不开就是这样，一直提示某个文件被锁定，没有提示具体的问题，将.config下生成的google-chrome删掉，问题就解决了，付出的代价就是你的用户相关的配置就没了）。
cd ~/.config/Code/logs
结论：
做过以上排查后，资源耗费不高，如果是假死肯定和资源无关。日志无明显异常，确定code本身应该没有大问题。我是远程桌面访问的远程主机上的vs code，切换软件都失效，点击vs code的c调试弹窗没有反应，以为是vs code假死导致系统假死。一直使用鼠标操作，后来使用键盘Tab尝试切换，关掉了vs code的弹框，一切就恢复正常了。
最后还是没有根因，不知是远程桌面的鼠标事件失效，还是xrdp server响应有问题。反正是确认vs code假死等待什么。本次仅做一次记录吧。
