唐朝汤圆_个人页

Java垃圾回收机制 其实Java垃圾回收主要做的是两件事：1）内存回收 2）碎片整理 3.1垃圾回收算法 1）串行回收（只用一个CPU）和并行回收（多个CPU才有用）：串行回收是不管系统有多少个CPU，始终只用一个CPU来执行垃圾回收操作，而并行回收就是把整个回收工作拆分成多个部分，每个部分由一个CPU负责，从而让多个CPU并行回收。并行回收的执行效率很高，但复杂度增加，另外也有一些副作用，如内存碎片增加。 2）并发执行和应用程序停止 ：应用程序停止（Stop-the-world）顾名思义，其垃圾回收方式在执行垃圾回收的同时会导致应用程序的暂停。并发执行的垃圾回收虽然不会导致应用程序的暂停，但由于并发执行垃圾需要解决和应用程序的执行冲突（应用程序可能在垃圾回收的过程修改对象），因此并发执行垃圾回收的系统开销比Stop-the-world高，而且执行时需要更多的堆内存。 3）压缩和不压缩和复制 ： ①支持压缩的垃圾回收器（标记-压缩 = 标记清除+压缩）会把所有的可达对象搬迁到一端，然后直接清理掉端边界以外的内存，减少了内存碎片。 ②不压缩的垃圾回收器（标记-清除）要遍历两次，第一次先从跟开始访问所有可达对象，并将他们标记为可达状态，第二次便利整个内存区域，对未标记可达状态的对象进行回收处理。这种回收方式不压缩，不需要额外内存，但要两次遍历，会产生碎片 ③复制式的垃圾回收器：将堆内存分成两个相同空间，从根（类似于前面的有向图起始顶点）开始访问每一个关联的可达对象，将空间A的全部可达对象复制到空间B，然后一次性回收空间A。对于该算法而言，因为只需访问所有的可达对象，将所有的可达对象复制走之后就直接回收整个空间，完全不用理会不可达对象，所以遍历空间的成本较小，但需要巨大的复制成本和较多的内存。

不要一次性把所有数据读入内存，要设置一个buffer，一部分一部分循环读取

创建一个变量，然后循环自增加大量的字符串，最终内存会比较容易出现溢出

可以通过cgroup限制进程对资源的使用，docker就是通过cgroup实现的

jmeter是一款开源的测试工具，如果要提高并发性能，那么就是要起更多的线程 开更多线程，意味着消耗更多的CPU及内存，尽量使用高配置的机器使用jmeter,监控CPU及内存使用，再做变配处理

局部变量在调用的时候才会创建，调用完毕后，生命周期也就结束了，资源被释放回收

静态变量创建后，是一直存储在内存中的，不会被释放， 如果是动态的，那么不再引用的话，程序会自动回收资源的

udp比tcp传输性能高是高，但是没有tcp的消息确认机制，会出现消息丢失，消息错误，修复重复等情况，这些tcp都是有机制保障的，所以tcp比udp慢

因为对象资源是存储在内存中的，创建了并不会被释放掉，所以过多的对象创建是很消耗资源的

时间换取空间，这是算法上面的衡量，要么消耗更多的时间（CPU），要么消耗更多的存储（内存），这个可以基于场景考虑，对于时间要求不高的，那么可以适当延长处理时间

首先要避免无限递归，要有中断条件的 只要有中断，就不会出现无限递归带来的资源耗尽问题

以网络内核参数为例，可以根据需要修改如下配置 # cat /etc/sysctl.conf vm.swappiness = 0 kernel.sysrq = 1 net.ipv4.neigh.default.gc_stale_time = 120 # see details in https://help.aliyun.com/knowledge_detail/39428.html net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.default.arp_announce = 2 net.ipv4.conf.lo.arp_announce = 2 net.ipv4.conf.all.arp_announce = 2 # see details in https://help.aliyun.com/knowledge_detail/41334.html net.ipv4.tcp_max_tw_buckets = 5000 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_slow_start_after_idle = 0

进程是在系统中，拥有分配资源的最小单位，进程可以生成子进程 在一个进程中（单线程），默认也叫线程，可以被CPU调度执行

可以通过mpstat查看 # mpstat 3 Linux 3.10.0-1160.41.1.el7.x86_64 (izbp152ke14timzud0du15z) 11/03/2021 _x86_64_ (4 CPU) 08:16:55 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 08:16:58 AM all 4.13 0.00 4.80 0.08 0.00 0.17 0.00 0.00 0.00 90.82 08:17:01 AM all 12.35 0.00 7.28 0.08 0.00 0.34 0.00 0.00 0.00 79.95 08:17:04 AM all 5.33 0.00 3.47 0.08 0.00 0.08 0.00 0.00 0.00 91.03

使用参考如下 # fdisk -l Disk /dev/vda: 85.9 GB, 85899345920 bytes, 167772160 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x000bde00 Device Boot Start End Blocks Id System /dev/vda1 * 2048 167772126 83885039+ 83 Linux # df Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 3856072 0 3856072 0% /dev tmpfs 3866488 0 3866488 0% /dev/shm tmpfs 3866488 5760 3860728 1% /run tmpfs 3866488 0 3866488 0% /sys/fs/cgroup /dev/vda1 82437788 72518048 6338352 92% /

可以使用pstack , strace，ptrace

并没有那种数据结构性能更优，只有适合的使用场景 例如： map 就适合快速查找,数组存储是连续的

tps低，CPU使用率低，证明CPU么有被充分利用，那么瓶颈可能就在其它地方，可以查看上下游服务，例如客户端压力机，后端连接的数据库服务等

可以通过dstat，iftop

可以使用dstat，vmstat，pidstat