下午面试美团JAVA，在美团的面试中，我居然被一个VARCHAR的长度问题搞得晕头了。一开始，我还信心满满，心想VARCHAR(50)和VARCHAR(500)不就是数字不一样嘛，谁不喜欢大号的？但是，面试官的一番话让我瞬间觉得，这个问题深似海。

VARCHAR(50) vs VARCHAR(500)

首先，VARCHAR(50)和VARCHAR(500)的差别，不仅仅是一个零的问题。虽然VARCHAR类型是变长的，意味着它只会使用实际存储数据所需的空间（加上一点点额外的长度信息），但是，这并不意味着我们就可以肆无忌惮地声明一个VARCHAR(500)。为什么呢？

所以，不是空间越大越好，而是应该根据实际需要合理选择。就像买衣服，你不会因为XXL没有限制你的活动范围，就不买合身的M号衣服吧？第一个问题我就有点抓耳挠撒了，平时crud写多了谁在意这个呢？

索引的使用

然后，面试官转到了索引上。假设我们有一个表t，有四个字段，id（主键），a，b，c，以及两个联合索引ab和ac。面试官问了我几个关于索引使用的问题：

接着，面试官问我在读取已提交（Read Committed）和可重复读（Repeatable Read）隔离级别下的共享锁和排他锁有什么区别。

哎，这个问题就更是让我觉得自己像是在做高空走钢丝。实现一个分布式锁？我可以用Redis来实现，通过SETNX命令来实现锁的互斥。至于可重入性，我会通过在锁信息中记录请求标识和重入次数来实现。

如果加锁过程中出现了network timeout，这就需要锁的实现能够检测到并处理这种异常情况，比如通过设置一个超时时间来自动释放锁。如果已经加锁成功，那么我们需要确保锁的释放逻辑是可靠的，以防止死锁。

在Redis主从部署的情况下，主从延迟可能会导致锁状态的不一致。解决这个问题，可以采用RedLock算法，或者确保所有的锁操作都在主节点上完成，并且从节点不参与锁的获取和释放。

至于如何评估Redission实现分布锁所需的hash结构的大小，这就需要考虑到锁的数量、使用频率以及Redis的内存管理机制。一个好的起点是监控现有的锁的使用情况，然后根据实际情况进行调整。

面试官又来了一个曲球，问我父线程用synchronized对某段代码加锁，子线程能获取到锁吗？答案是不能。synchronized锁是基于线程持有的，而不是基于调用的。所以，即使是在父线程创建的子线程中，也无法获取父线程持有的锁。

至于JVM调优，我确实有一些实战经历。我曾经遇到过一个服务频繁Full GC的问题，通过分析GC日志和内存转储文件，我发现是由于老年代被一个大的HashMap占满导致的。通过调整JVM参数和优化代码，我最终解决了这个问题。

内存泄漏？这个问题让我想起了那些漫长的夜晚，用工具（比如MAT、VisualVM等）分析堆转储文件，寻找那些生命周期过长的对象，检查它们的引用链，最终定位到泄漏的原因。

至于Full GC的原因，哦，这个问题让我想起了老友记中的罗斯，他会说：“你是想听开始的原因，还是中间的原因，还是结果的原因？”老实说，Full GC可能是由多种原因引起的，比如内存泄漏、JVM参数不当、系统负载过高等等。

总之，这次面试让我深刻意识到，技术的海洋是深不可测的，即使是一个简单的VARCHAR长度问题，也能让人栽跟头。不过，我相信，每一次跌倒都是成长的机会。下次再遇到这样的问题时，我一定能够从容应对。美团，下次我还会来的！