Contents

ARST打卡第278周

lc3127_构造相同颜色的正方形 TED演讲_欲责人先责己,找hack方案 剖析 stl+glibc “内存泄漏” 原因 内存分析流程

Algorithm

lc3127_构造相同颜色的正方形

思路:

今天每日一题过于简单,就是把两种颜色一个当0,一个当1,然后遍历所有2*2格子,取值0,1,3,4皆为true。

因此尝试用 rust 写。

一开始一直想着rust for i如何双重遍历,后面才想到可以像c/c++一样直接用下标。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
impl Solution {
    pub fn can_make_square(grid: Vec<Vec<char>>) -> bool {
        let n = 3; // 网格大小为3x3

        // 遍历整个3x3的网格,检查所有可能的2x2子矩阵
        for i in 0..n-1 {
            for j in 0..n-1 {
                // 计算2x2子矩阵的值
                let mut value = 0;
                if grid[i][j] == 'B' { value += 1; }
                if grid[i][j+1] == 'B' { value += 1; }
                if grid[i+1][j] == 'B' { value += 1; }
                if grid[i+1][j+1] == 'B' { value += 1; }
                
                // 如果值为0, 1, 3, 4,返回true
                // 实践发现 != 2 比下面操作多花 0.15MB,下面or只要2MB,而不等于要2.15MB
                // if value != 2 {
                if value == 0 || value == 1 || value == 3 || value == 4 {
                    return true;
                }
            }
        }
        
        // 如果没有找到符合条件的2x2矩阵,返回false
        false
    }
}

Review

TED演讲_欲责人先责己,找hack方案

演讲者主要讲的内容就是想要大家一起解决问题时需要这样做:

  1. Don’t blame – 不要指责别人, 先找自己的问题 和某蓝厂的欲责人先责己文化相同,可惜蓝厂某些人并没有遵守这些文化
  2. Look in the mirror – 看看自己为啥认为别人应该做好,是什么别人比自己缺少了什么工具才没做好的.
  3. Engineer the solution – 找到解决方案,制定系统型或者制度型的解决方案规避下次发生问题.

Tips

剖析 stl + glibc “内存泄漏” 原因

这篇文章从Centos压测发现进程内存不释放,发现 stl 结合 glibc 会触发 “内存泄露” 问题。 过程中对进程内存使用提供了示例以及源码级别的讲解,通俗易懂,有助于对内存管理有个更好的理解。

Share-内存分析流程

在分析内存的过程中,可以搭配许多Linux的命令工具来进行。以下是一套内存分析的基本思路:

  1. 先用free和top,查看系统整体的内存使用情况。
  2. 再用vmstat和pidstat,查看一段时间的趋势,从而判断出内存问题的类型。
  3. 最后进行详细分析,比如内存分配分析、缓存/缓冲区分析、具体进程的内存使用分析等。

第一步和第二步可以观察到内存问题的现象。

第三步中对内存的使用情况进行分析。需要结合业务代码,对问题的根因提出假设,并配合一些工具来验证假设。

分析的过程需要以下步骤不断循环:提出假设,收集数据,验证假设。

最终才能得出结论。

还得结合上面 Tips 推荐的文章,要学会把思路打开,不仅要分析自己的业务程序,还要分析业务程序使用的系统内存组件的问题。