经过了几天的熟悉环境，小鱼开始让飞鸟尝试负责解决一些问题。分配的第一个问题现象是这样的：
接口有偶尔的超时现象。平时的时候接口可以在2s响应调用的上游。但是偶尔会有几次，超时特别严重，有时候20s、30s才返回。但是上游的超时时间是10s。所以这时候上游是拿不到结果的。对上游来说这次请求失败了。
飞鸟通过排查，找到了一些线索，就抱着电脑去找小鱼。
接口超时造成的上游请求失败是一个可用性的问题。为了解决这个问题，就需要优化系统，提高响应速度，这是一个性能的问题。具体到问题里，因为用到了锁，对性能造成了影响。可以通过优化这个锁性能来解决。即：
目标：
可用性
手段：
性能优化
抓手：
优化锁性能
可用性和性能不同的人有不同的理解。
可用性一般指正常运行时间占总时间的百分比。对上游来说，超时是一种不可用状态。
性能是指系统或服务在具体事情的时候表现如何。严格来说可用性也是性能的一个指标。
对于单接口来说，接口不可用大体分为下面四个方面：
- 接口内部异常
这个多为系统bug，如常见的空指针NPE、内存泄漏等。
根据问题解决问题即可。
b.接口没在限定的时间内返回
如今天的锁等待导致的超时问题。
这个问题解决一般需要依赖监控数据，如各个链路调用的处理时间。根据各个环节耗时情况和处理逻辑进行相应优化。常用优化方式如：异步化、并行化、改造耗时逻辑等。
c.接口不提供服务
如接口被降级或者系统崩溃。
解决这个问题需要从系统和架构上考虑。
d.接口响应其他原因没到达调用方
如被限流、网络不通等。
解决这个问题系统要做好服务治理和全链路监控。
性能方面，今天就先说一下一些性能参考指标：
- 执行时间
一段代码从开始运行到运行结束所使用的时间。
- CPU时间
（算法）函数或者线程占用CPU的时间。
- 内存分配
程序在运行时占用的内存空间
- 磁盘吞吐量
描述I/O的使用情况
- 网络吞吐量
描述网络的使用情况
- 响应时间
系统对某用户行为或者动作做出响应的时间
最后说一下锁，分布式锁比传统的线程锁和进程锁开销要大很多，但是它解决了跨JVM来进行共享资源的访问问题。目前主要有三种实现：
- 基于数据库实现的分布式锁
- 基于缓存实现的分布式锁
- 基于zookeeper实现的分布式锁
不管是哪种锁，一旦用到锁，就说明是阻塞式的。所以再并发度上一般来说都会比无锁的情况低一点。锁优化的思路和方法总结一下，有以下几种：
- 减少锁持有时间
- 减小锁粒度
- 锁分离
- 锁粗化
- 锁消除
