java

  • 反模式的接口常量

    在实际开发过程中,经常会需要定义一个文件,用于存储一些常量,这些常量设计为静态公共常量(使用 public static final 修饰)。这个时候就出现两种选择:

    1. 在接口中定义常量,比如 JDK 1.1 中的 java.io.ObjectStreamConstans 接口;
    2. 在类中定义常量,比如 JDK 1.7 中的 java.nio.charset.StandardCharsets

    这两种方式都能够达到要求:存储常量、无需实例化。下面分情况讨论下两种方式孰优孰劣。

  • Java注释总结

    在Java的编写过程中我们需要对一些程序进行注释,除了自己方便阅读,更为别人更好理解自己的程序,所以我们需要进行一些注释,可以是编程思路或者是程序的作用,总而言之就是方便自己他人更好的阅读。

  • 主线程等待子线程结束

    在很多时候,我们期望实现这么一种功能:在主线程中启动一些子线程,等待所有子线程执行结束后,主线程再继续执行。比如:老板分配任务,众多工人开始工作,等所有工人完成工作后,老板进行检查。

    解决方法分析:

    1. 主线程通过join等待所有子线程完成后,继续执行;
    2. 主线程知道子线程的数量、未完成子线程数量,主线程等待所有子线程完成后,才继续执行。

    3. 使用FreeMarker替换JSP的10个理由

      你还在使用 Java Server Pages(俗称JSP,Java服务器页面)吗?我曾经也是,但是几年前我抛弃了它们,并且再也没有用过JSP了。JSP 是个很好的概念,但是它却剥夺了 web 开发的乐趣。 对我而言,这些都是小事,比如无法在页面模板上使用单独的文件header.jsp 和 footer.jsp,不能调用表达式语言的方法,在运行时无法合并,重新排列页面的各个部分。所以我转而使用 FreeMarker 模板。FreeMarker 已经存在一段时间了,如果你最近没有关注过 FreeMarker 的话,那这有些建议给你,让你考虑下个 web 应用使用 FreeMarker。

    4. 再谈CountDownLatch

        java.util.concurrent.CountDownLatch是JDK 1.5提供的一个同步辅助类:在一组正在其他线程中的操作执行完成之前,它允许一个或多个线程一直等待。

        初始化CountDownLatch时需要指定计数。通过调用countDown方法使当前计数到达零之前,await方法会一直阻塞。之后,所有等待的线程会被释放,await后面的操作也会立即执行。因为计数无法被重置,所以这种操作只会出现一次。如果需要重置计数,请考虑使用java.util.concurrent.CyclicBarrier。

    5. 八皇后问题

      八皇后问题,以国际象棋为背景:如何能够在 8×8 的国际象棋棋盘上放置八个皇后,使得任何一个皇后都无法直接吃掉其他的皇后?为了达到此目的,任意两个皇后都不能处于同一条横行、纵行或斜线上。

    6. 再谈CyclicBarrier

        java.util.concurrent.CyclicBarrier也是JDK 1.5提供的一个同步辅助类(为什么用也呢?参见再谈CountDownLatch),它允许一组线程互相等待,直到到达某个临界点(a common barrier point,翻译成公共障碍点、公共栅栏点都不够传神,直接用临界点吧)。在某个程序中,一组固定大小的线程必须互相等待时,CyclicBarrier将起很大的作用。因为在等待线程被释放后,这个临界点可以重用,所以说是循环的。

    7. java.lang.OutOfMemoryError:GC overhead limit exceeded

      java.lang.OutOfMemoryError这个错误是比较经典的错误了,经过JDK不断的迭代,服务器硬件的不断升级。。。总之,社会在发展,时代在进步。很多错误已经消失在时代的浪潮中。我也是很久没有见过这个错误了,以至于都以为在Java的世界中不会再碰到这个错误。结果,就在最疏忽的时候碰到了TA,真是,心中一万只神兽奔袭而过,狠狠的践踏了我这颗上了年纪的心脏啊。

      吐槽完毕,言归正传。

      Java刚刚出现的年代,有一个相比于其他语言的优势就是,内存回收机制。不需要明确的调用释放内存的API,java就自动完成,这个过程就是Garbage Collection,简称GC。这对以懒著称的程序猿们来说,绝对是重大利好。但是,凡事有利必有弊,可以肯定的是,Java语言是人创造的,GC也是人编写的代码,绝对不是机器自动完成的。也就是说,GC的过程是另外一群程序猿根据可能出现的情况,预设了GC条件,把符合回收条件的内存空间释放出来。一旦被占用的内存空间不符合释放的条件,GC没办法清理,那就会适时出现java.lang.OutOfMemoryError。这个错误就是提醒我们这群程序猿,写GC程序的程序猿不知道这种情况怎么处理,为了安全也不便处理,谁使用Java就自己看着解决吧。

      说起来,java.lang.OutOfMemoryError有几种分类的,这次碰到的是java.lang.OutOfMemoryError: GC overhead limit exceeded,下面就来说说这种类型的内存溢出。

    8. JVM参数优化(基础篇)

      这几天压测预生产环境,发现TPS各种不稳。因为是重构的系统,据说原来的系统在高并发的时候一点问题没有,结果重构的系统被几十个并发压一下就各种不稳定。虽然测试的同事没有说啥,但自己感觉被啪啪的打脸。。。

      于是各种排查,最先想到的就是JVM参数,于是优化一番,希望能够出一个好的结果。尽管后来证明不稳定的原因是安装LoadRunner的压测服务器不稳定,不关我的系统的事,不过也是记录一下,一是做个备份,二是可以给别人做个参考。

    9. JDK 工具一览

      Java 坑如此大,需要慢慢填。

      本文是列出JDK自带的一些工具,介于篇幅,简单列出工具列表及工具的作用。至少先做到知道有哪些工具,然后才能在实际中用到。

      本文参考了官方介绍和本机man命令的介绍。