这个文章挺好的，分享给大家，用 go 实现了漏桶算法 https://zhuanlan.zhihu.com/p/441005648

@jdhao 前几天投了简历以后，一直没信儿，老哥你之前投过吗

@zzzzzzZ 我就是个初级程序员，面试官是蚂蚁的

@hidemyself 他问的是解决方案，不是问我他们的利弊，利弊他给我介绍了

@sunny1688 redis 只用集群的话，有死锁的可能吧，如果一个节点挂了的话，redis 官方提供了 redlock 的分布式锁解决方案，但是这个也有问题，有人质疑这个并不能保证分布式环境下的锁的安全问题

几个大厂小厂基本一面挂，两年 java 经验，原来在北京中厂，现在准备看海外的机会了

@BBCCBB 点赞，我其实就是去哪儿出来的哈哈哈，用 qmq 的时候没注意，原来延时消息其实是不那么好实现的

1.5Year 经验能投吗

@L0L FullGc 会回收，但是 yougGc 不会，YoungGc 的确需要扫描字符串常量池

@zmal 这个问题很多人遇到过

@zjp 不是这个，是 string.intern()方法，导致字符串常量池里的 stringTable 缓存了过多的字符串，增加了 yougGC 的扫描耗时

@Macolor21
这是 JackSon 的 intenCache 的源码，为什么入参的 input 你认为一定是一个字符串常量池的引用呢，如果假设现在的 json 串的 Key 是字符串“name”，我认为执行这个方法的入参的这个字符串 Input 对象，一定是一个新的，在堆区分配空间的字符串对象
public String intern(String input) {
String result = (String)this.get(input);
if (result != null) {
return result;
} else {
if (this.size() >= 180) {
synchronized(this.lock) {
if (this.size() >= 180) {
this.clear();
}
}
}

result = input.intern();
this.put(result, result);
return result;
}
}

@Macolor21 耗时相比起直接就返回入参的字符串，难道不是一定会更慢吗，但是节省了空间是一定的

@urnoob 可能是我写的顺序有误，其实只是想说下之前遇到这个问题的背景，背景跟问题无关，我的意识并不是说为什么我用了 intern string 变慢了，但是官方说 string.intern 可以减少时间，我的问题只是想问，为什么 intern.string 作为缓存，减少耗时，变快

@urnoob gc 为什么一定会变快呢，入参穿进来的字符串一定是一个新的字符串啊，一定需要被 gc 掉，如果使用 return string.intern()的话，这个入参会被 gc 掉，如果直接返回这个入参字符串的话，就相当于多占用了一份空间，在未来的某个时间可能会被 gc ，但是这两种情况都会有一个相同的垃圾需要被 gc ，也就是入参传进来的那个字符串

@sutra 我们遇到的就是这样的问题，接口传来了不同 Key 的 json ，反序列化导致了 stringTable 一直缓慢的膨胀