接口里多灌点数据进去吧，也算为人民服务了

入正好久了，前年程序员节活动送 2 年真的爽。1k 多对于程序员应该也就 1,2 天工资吧，我觉得这个投入完全没问题。

c87 三年正常服役

不是很懂为啥你们的电池健康掉这么快，iphone12 首发到现在还有 100%健康。。。

咋一看有点像 redis 的序列化协议 redis.io/topics/protocol

借钱就不要委婉了，会拒绝人也是一个重要的社交能力。直接果断说自己也没钱，不借就行。

某些场景下，我觉得是 app 就是想让你看开屏广告，看完广告又回到之前那个页面了。

@jianzong #160 嗯，我的意思是，只有归档的账户在设置里才可以删除，而未归档的账户没有 [显式] 的删除方式

之前好像实现过一个，通过声明一个 Request 作用域的 Bean 实现，构造函数里直接随机一个字符串

没人觉得 mybatis 也很麻烦啰嗦么，xml 配置没有类型安全（指编译时检查）我就觉得很淦。

在后台一些场景（如一个商品列表，需要展示商品信息，店铺信息，收藏人数）在动态查询的时候 Specification 和 mybatis plus 都是啰啰嗦嗦几十行，不知道大家在这种场景下是怎么干的。。。

代码不全，应该是自己代码的问题，可以看以下例子。
```go
package main

import (
"encoding/json"
"fmt"
)

type JsonResponse struct {
Code int `json:"code"`
Data interface{} `json:"data,omitempty"`
}

func main() {
data := []int{1, 2, 3, 4, 5}
bs, _ := json.Marshal(JsonResponse{
Code: 0,
Data: data,
})
// {"code":0,"data":[1,2,3,4,5]}
fmt.Printf("%s", bs)
}
```

话说直接断点调试下不就知道数据对不对了

@jianzong #154 详情里加个删除按钮觉得挺好，做个二次确认应该就可以避免不小心删除的问题。

另外提个逻辑 BUG ？就是未归档的账户是不会在设置里的= =导致我找了半天删除按钮，结果试了半天的左滑 [笑哭]

反馈个问题，添加的账户使用 [左滑删除] 有点太让人抓狂了，一直左滑不出来

设备：iPhone12
录屏： https@@@mega.nz/file/3s1yHY6D#iFzxClmPME9-C7MNpH0jfFOicPxvWGuBPJ8eoKOZB00

视频操作的都是 [招行储蓄卡] 这个条目，一直滑不出来，不知道是不是我的操作方法有问题，太让人抓狂了

我也很烦这个，不过这个似乎是 app 本身的行为。估计是每次进入都检查并且弹一次...

@jianzong #143 感谢赠码 https://i.v2ex.co/9j4yR89H.png

730 doge

其实从阿里云监控数据显示，内存占用是逐步上涨的，大概每 5 分钟上涨 0.01%（~0.7m ），所以我最初的调查方向都是以内存泄露为主 [捂脸]

@XiaoxiaoPu #6 嗯哈，昨晚我也看到了 https@@@zhuanlan.zhihu.com/p/25241630 这篇文章里的讲解，结合我的实际情况（绝大多数是每隔 20s 的 ping/pong 心跳，服务端直接响应 pong，不做任何处理）考虑，我觉得 socket 应该不会暂存这么多的数据。昨晚升级了服务器，现场数据已经没了 [捂脸] ，不过今天看了下，大致是能对的上了。以下是 slabtop 的数据，看起来 socket 其实也没有那么大？

```plain
Active / Total Objects (% used) : 381214 / 384110 (99.2%)
Active / Total Slabs (% used) : 14068 / 14068 (100.0%)
Active / Total Caches (% used) : 73 / 101 (72.3%)
Active / Total Size (% used) : 136913.44K / 137986.20K (99.2%)
Minimum / Average / Maximum Object : 0.01K / 0.36K / 8.00K

OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
75054 74990 99% 0.19K 3574 21 14296K dentry
46956 46956 100% 0.10K 1204 39 4816K buffer_head
32832 32553 99% 0.06K 513 64 2052K kmalloc-64
23472 23296 99% 0.66K 978 24 15648K proc_inode_cache
21808 21455 98% 0.25K 1363 16 5452K kmalloc-256
21392 21261 99% 0.07K 382 56 1528K avc_node
21024 20410 97% 0.12K 657 32 2628K kmalloc-128
19900 19713 99% 0.62K 796 25 12736K sock_inode_cache
19710 19513 99% 2.06K 1314 15 42048K TCPv6
16286 16286 100% 0.12K 479 34 1916K kernfs_node_cache
14283 14283 100% 0.58K 529 27 8464K inode_cache
11744 11744 100% 1.00K 734 16 11744K ext4_inode_cache
11424 11424 100% 0.04K 112 102 448K selinux_inode_security
5418 5418 100% 0.21K 301 18 1204K vm_area_struct
4864 4864 100% 0.02K 19 256 76K kmalloc-16
4096 4096 100% 0.01K 8 512 32K kmalloc-8
3500 3500 100% 0.57K 125 28 2000K radix_tree_node
3366 2613 77% 0.08K 66 51 264K anon_vma
3315 3315 100% 0.05K 39 85 156K shared_policy_node
3264 3264 100% 0.04K 32 102 128K ext4_extent_status
1792 1792 100% 0.03K 14 128 56K kmalloc-32
1785 1785 100% 0.19K 85 21 340K kmalloc-192
1722 1722 100% 0.09K 41 42 164K kmalloc-96
1584 1584 100% 1.00K 99 16 1584K kmalloc-1024
1184 1079 91% 0.50K 74 16 592K kmalloc-512
1080 1080 100% 0.11K 30 36 120K jbd2_journal_head
912 912 100% 0.66K 38 24 608K shmem_inode_cache
680 680 100% 0.02K 4 170 16K fsnotify_mark_connector
567 567 100% 0.19K 27 21 108K cred_jar
544 544 100% 0.12K 17 32 68K pid
540 540 100% 0.11K 15 36 60K task_delay_info
```

@kele1997 #5 可能是我没表达清楚，我的想法是，这台机器只运行了一个 java 程序，在 top 里显示 RES 为 5g，但是 free 里显示已用 6.8g 。然后根据 1 楼所说我去查了相关资料，现学现卖发现还是会有 1g 的内存出入（ slab 等加上 5g 之后）

在 free 和 top 里显示的差距应该部分缓存导致的，我想表达的是在 top 或者 free 里看到的内存占用与实际进程相加相差过大的问题