暂无个人介绍
2021年11月
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