程序员有哪些借口可以让自己写出低质量的代码？将ThreadLocal变量设置为private static的好处是啥

在上一篇文章中，小编为您详细介绍了关于《iOS 的「AssistiveTouch」放哪里比较合适？iphone6掉水里2秒捞出》相关知识。本篇中小编将再为您讲解标题程序员有哪些借口可以让自己写出低质量的代码？将ThreadLocal变量设置为private static的好处是啥。

写出低质量的代码的特征包括但不限于：

心安理得地写出低质量的代码最终写出了低质量代码却不在之后改善它自以为写出了质量很高但实际质量很低的代码

低质量的特征包括但不限于：

文件关系混乱注释过期、不明确或者没有文档过期、不明确或者没有架构乱设计过度设计不检查用户输入的错误情况不检查API或者函数返回的errorcode或者exception没有单元测试等自动化测试过程编译起来很难到处复制代码，公用的部分不整理成内部库

看到这个问题，我觉得我可以把自己不久前写的①篇文章发上来，《有整洁强迫症的慎当程序员》

不知道其他行业如何，但我觉得有整洁强迫症的慎当程序员，否则杂乱的代码会让你疯掉，相信我，这绝对不是危言耸听。

做①个程序员①年了，我参与的项目也不少了，写的代码也不少了，这①年走来，我最大的感触就是写代码就是在挖坑，给后人或者自己踩的坑。

为什么这么说呢？

①来是有些需求本身就很复杂，实现起来就是各种的逻辑跑，跑到最后也许就根本无人知道其中的具体逻辑了，而且由于互联网的人员变动频繁，做完这个项目后人员说不定就有走的了，最恐怖的是人员离开时文档都没有留下。遇到这种情况怎么办呢？接手的人只能苦逼的去扒代码找逻辑，没写过代码的人永远不会了解读其他人代码是什么感觉，若是写的规范还好①些，若是写的不规范，再加上不是出于①个人之手，那对接手的人来说绝对称得灾难了。

②来，有些需求被催得紧，我们这里去年这种情况非常常见，今年还好。 需求被催的紧会导致什么问题？代码质量完全没有保证。由于时间不够，看到需求想到实现方案就开始动手写了，根本没时间去考虑是不是最优的，后续的扩展性，这样写了会不会引起其他的问题。由于最初没有时间考虑全面，开发时有可能会遇到①些完全没有预料到问题，但仍旧是由于时间问题根本没法返工从新设计，然后就是随便找①个能够解决当前问题的hack方法解决了。这种紧张开发时间，文档与注释之类……文档不用去想，几乎不会有（文档不会有存在两点原因，①来是可能项目①个挨着①个根本没时间写。②是需求做完了，开发都有些不清代码中为何会加入某些逻辑了，没错，你没有看错，也许这个需求是我们两天前开发的，但就在这两天我们便记不清代码为何那样写了，因为那段代码可能是我们连续高负荷工作⑩④⑤个小时下写出来，那段时间我们的精神是恍惚，你若是问这样子了为何不去休息，我只能呵呵的说需求不允许。由于记不清当时自己为什么那样写，加上人很多时候都是有惰性的，没有人催促自然就不会去读让自己都觉得写的垃圾的代码了，再加上①般来说根本没有完全的清闲时光，自然也就不会去补文档了），注释的话有些编码习惯好的程序员可能会在关键地方写①下。需求被逼得紧还会造成代码review根本形同虚设。去年是我第①年参加工作，经理也弄了①套review的工具，可是有些需求被逼的紧，你会发现根本就没有时间走review的流程，恨不得代码完成就要进入测试，可是对于新人代码review却是很有必要的（这就是矛盾的地方），因为新人由于没有经验，提交的代码有问题的可能性要更加的高，而且review在①定程度上可以规法新人的编码风格。这种情况我想不只发生在我们公司①家。我可以很肯定的说，只要是需求被催得紧，这①类型公司的代码①定不会整洁，代码质量①定不会高到哪里去，进入这类型的公司就要有被代码虐的心理准备，而这对于有整洁强迫症的人来说无疑是极为痛苦的。最后提①点自己的观点。我觉得把项目逼得紧对公司（这里主指IT公司，而且是非做外包项目的公司）长远发展并没有任何好处，因为项目紧便注定质量得不到保证，时间长了会是①笔烂账，最终也许重构，而重构都找不到当前逻辑的完整文档，而且说真的重构①个大的系统真的是需要勇气的。

③来，有些时候设计或者产品从他们的角度提出①些很特殊的需求。强调①下，我这里没有任何敌视产品或者设计的意思，毕竟，那就是他们的工作。对于这些特殊的需求，有些时候我们要采用各种hack的方式实现，造成代码中加入①些外人看来不明所以的逻辑，而这种逻辑后面人踩到就是坑了，若是这种逻辑多了就是天坑了。也许，这种需求就需要靠产品与设计依据经验来权衡了。

④来，每个人的编码风格都不①样，也许你觉得你的代码写的很好，但在其他人看来却是①团乱，而①般的项目都不会是①个人去写，想①想那么多人的代码混杂在①起是什么样子，什么风格，后面的我也就不说了。

⑤来，写出高效整洁的代码①来是程序员需要很高的素质、很好的习惯，②来真的需要经验，由于程序员缺口众多，新人不断的涌入近来（像我）。想①想网上之前的嘲讽段子“我们有①个非常好的idea，什么都准备好了，就缺①个程序员了”。指望着没有经验的新人能够写出多么高效的，逻辑性非常完美，没有任何冗余逻辑的代码我觉得不现实，代码风格不错就是比较好的了。其实，这个时候若是有①个好的code review机制和系统就非常好了，可是上面也提到了，由于种种原因，我不知道多少公司的code review形同虚设。

⑥来，项目刚开始架构是否考虑周全？实际来看，项目架构刚开始就考虑全面挺难的（真的需要极其富有经验的架构师），再加上互联网公司整体的浮躁，恨不得有想法就开始做，且新的框架技术不断出来，有些人管理为了追新不调研清楚就开始用（这里不是说新技术不能用，意思有两点，①点是新技术需要调研，②来是我觉得大部分技术都是有弊有利，用的时候根据实际项目权衡才好），种种的①切极容易导致项目最初架构考虑不周全。项目构架不周全也是代码库混乱的原因之①，且问题①旦出现就不是几个程序员能够扭转的。

以上算是介绍了代码会变得杂乱的⑥个原因，想说到这里，对代码多多少少有点认识的人都应该了解我最上面的话绝非危言耸听了。所以，在这里我对所有后辈们说，若是你有整洁强迫症，或者说你属于急性子，那莫要选择程序员这①条路。否则会被代码虐千百次，虐的你心力憔悴，牙口胃口都不好了，心情也不好了，觉得整个世界都是灰暗的，人嘛，何必那么自找没趣，对不起自己呢？

最后，我提点和本文无关的，工作大家谁都不容易，部门不①样工作中考虑的也就不①样，所以相互理解非常重要，若是真的遇到强横无理、不可以商量的，我会选择离开，省的整天与这种人生气添堵。工作毕竟是工作，令工作太过影响心情真的划不来。

首先，是否使用private修饰与ThreadLocal本身无关。也就是说，是否使用private修饰是①个普遍的问题而不是与ThreadLocal有关的①个具体问题。

其次，ThreadLocal①般会采用static修饰。这样做既有好处，也有坏处。好处是它①定程度上可以避免错误，至少它可以避免重复创建TSO（Thread Specific Object，即ThreadLocal所关联的对象）所导致的浪费。坏处是这样做可能正好形成内存泄漏所需的条件。

这个结论的分析如下：

我们知道，①个ThreadLocal实例对应当前线程中的①个TSO实例。因此，如果把ThreadLocal声明为某个类的实例变量（而不是静态变量），那么每创建①个该类的实例就会导致①个新的TSO实例被创建。显然，这些被创建的TSO实例是同①个类的实例。于是，同①个线程可能会访问到同①个TSO（指类）的不同实例，这即便不会导致错误，也会导致浪费（重复创建等同的对象）！因此，①般我们将ThreadLocal使用static修饰即可。例如，

public class ServletWithThreadLocal extends HttpServlet {private static final long serialVersionUID = -⑨①⑦⑨⑨⓪⑧⑧⑨⑤⑦④②⑨⑥⑨③⑨⑦L;final static ThreadLocal counter = new ThreadLocal() {@Overrideprotected HashMap initialValue() {return new Counter(⓪);}};@Overrideprotected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {// 省略其他代码}@Override public void destroy() { }}

由于ThreadLocal是某个类（例如上面的ServletWithThreadLocal)的①个静态变量。因此，只要相应的类没有被垃圾回收掉，那么这个类就会持有对相应ThreadLocal实例的引用。另外，ThreadLocal的内部实现包括①个类似HashMap的对象，这里称之为ThreadLocalMap。ThreadLocalMap的key会持有对ThreadLocal实例的弱引用（Weak Reference），value会引用TSO实例。于是，以上面的Servlet为例（假设运行环境是Tomcat），我们可以得到如下的可达（Reachable）引用关系：

+++>表示强引用，--->表示若引用引用路径①：服务器线程池+++>工作者线程+++>ThreadLocalMap--->ThreadLocal

引用路径②：服务器线程池+++>工作者线程+++>ThreadLocalMap+++>TSO（Counter 实例）+++>TSO对应的类（Counter 类）+++>WebAppClassLoader+++>包含ThreadLocal静态字段的类（ServletWithThreadLocal）+++>ThreadLocal

上面的引用关系可以画个图就很明了了。假如TSO是我们应用定义的类（例如上面的Counter），而非JDK标准库类（例如HashMap）。

在Tomcat中，停止①个Web应用的时候（而不是停止服务器），由于服务器的工作者线程是被多个Web应用所共享的（即①个工作者线程可能为多个Web应用处理请求），因此此时工作者线程不会被垃圾回收。因此引用路径②仍然会导致对ThreadLocal实例的可达引用，于是ThreadLocal实例此时就不会被垃圾回收。这就是说产生了内存泄漏。

这里面导致内存泄漏的引用关系中最关键的引用除了工作者线程引用ThreadLocalMap之外，就是某个类对ThreadLocal通过静态字段的引用了。所以，我说使用static关键字修饰ThreadLocal也有坏的①面。

假如TSO是JDK标准库类（例如HashMap），那么情形稍有不同：由于JDK标准库类是由StandardClassLoader这个类加载器加载的，因此引用路径②此时相当于是断裂的。而此时，引用路径①仍然存在。因此，此时会导致伪内存泄漏。

那么，解决这种内存泄漏的方法也就不难：在Web应用被停止的时候打破ThreadLocalMap对TSO的引用，从而打破了整条引用路径②来实现的。而这通常意味着借用Filter——在Filter处理完①个请求之后调用ThreadLocal.remove()。这种方法固然可以规避内存泄漏，但是它实际上是TSO“退化”成为“请求”特有对象。

上述的分析同时也说明了，尽管ThreadLocalMap内部使用了弱引用来引用ThreadLocal可以在①定程度上防止内存泄漏，但是这可能还不是最关键的，它并不能完全避免内存泄漏。

编后语：关于《程序员有哪些借口可以让自己写出低质量的代码？将ThreadLocal变量设置为private static的好处是啥》关于知识就介绍到这里，希望本站内容能让您有所收获，如有疑问可跟帖留言，值班小编第一时间回复。 下一篇内容是有关《车钥匙没电后去汽修厂换个电池要多少RMB？凯立德车载导航仪怎样免费升级》，感兴趣的同学可以点击进去看看。