这几年来，我特别喜欢看关于性能优化的文章．基本上是每看到一篇，都会去看．然而，我发现这些文章大多是倾向于数据库层面的优化，系统硬件层面的优化．
这本身无可厚非，因为写那些文章的，大多数都是大厂的工程师，因为会有Code Review,代码的质量都会有所保证．
但是，对于我们学生来说，调优的时候，关注数据库等方面的调优，就一定有效吗?换句话说，就是，数据库等，一定是你的系统的瓶颈吗?
比方说，调优时，为了增大数据库的处理能力，我们可能会选择增加数据库能够建立的连接，加大数据缓冲区的大小．为了让服务器能够处理更高的并发量，我们可能会增加文件句柄数．
然而，我们增大了数据库的处理能力，让其能够建立更多的连接，我们的系统的性能就一定会提升吗?
假设之前数据库能够建立1000个连接，现在我们为其增大到2000,我们的期望是，数据库连接增大了，现在我能够处理HTTP请求数也应该翻倍．
然而，实际上，系统的QPS上不去，可能是由于存在大量的文件读写操作，从而使线程都阻塞在IO上，也可能是服务器就能够承受400的QPS,但是，同时来了1000个请求．这样，就算数据库能够建立的连接数再大，有用吗?
我们也可能用增大服务器上的文件句柄的数量的方式，来增大能够同时处理的请求数．在文件句柄是瓶颈的情况下，这么做是正确的．但是，在代码层面，可能忘记释放文件句柄．这样，最终因为获取不到文件句柄而导致服务器不能处理请求，是必然的．
我们写并发程序时，也需要进行同步．我们都知道，Java中的synchronized是粗粒度的，它使某一段代码，同一时间，只能有一个线程来执行，使并行变成了串行．有的时候这就变成了瓶颈．而如果我们考虑到具体的情况，比如，这段代码是不是可以同时被多个读线程读，而切换到ReadWriteLock,就能解决这种瓶颈．
所以说，其实我们在优化系统时，可能代码层面还有很大的可以优化的地方，把代码优化到极致，然后在根据测试结果，进行相应的优化，才能实现最好的优化结果．
我们在学习性能优化的时候，也不要为了学习优化而学习优化．工业界不是有一句话嘛，不谈业务的设计都是耍流氓．分析业务特点，将代码优化到极致，再根据系统的测试结果，进行相应层面的优化，才是王道．
纯属个人感悟，让各位见笑了．
