@datiewang 我不会日语....只会英语，之前在小红书上联系上了一个在东京的华人猎头

@clouddd profile 我尽量的在改进了，关键词是指什么呢，看来是不是还是付费服务起了作用

@Znemo 也就是应用层的丢消息，这样理解对吗?也就是 tcp 能保证数据能够传输到目标主机的网卡里，但是并不保证后续的数据是不是被应用层读取，这么理解对吗

之前面了字节两次一面挂还能面吗

@zzzzzzZ 他问我怎么做幂等，我说用数据库唯一键，然后他说数据库只能是插入场景可以用，修改的场景呢，我说做幂等就建一张幂等表，用业务的唯一 id 做唯一索引，不管是什么业务逻辑要做幂等，都可以用这张表做，我觉得他可能没理解数据库唯一键怎么做幂等，不过我觉得他问我的这个分布式锁的问题，如果让我这个工作了两年不到的程序员回答，有困难，但是我觉得问题有讨论的价值

@leonme 令牌桶允许一段时间得突发流量，也就是令牌缓存得比较多得时候，允许超过限流得流量，但是漏桶强行的限定了水流出的速率

这个文章挺好的，分享给大家，用 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 耗时相比起直接就返回入参的字符串，难道不是一定会更慢吗，但是节省了空间是一定的