• 《100 Java Mistakes and How to Avoid Them》笔记 3

    calendar Dec 28, 2023 · 4 min read · Java  ·
    Share on: linkedin copy
    本书的阅读又搁置了许久，虽然感觉 Manning 出版社的这一 100 Mistakes 系列从书的质量不是那么的高，但开了头还是继续从本书 40% 的位置往下。


    开始要讲述到异常了，异常还是有必要认真对待的，比如

    1. Java 中很容易被 CheckedException 弄得代码不整洁
    2. 缺少必要的参数检查，不舍得抛出异常，视异常为 Bug
    3. 不明确出现异常时后续如何处理，
    4. 或者是捕获而隐藏了异常致使定位错误变得更难。

    Java 的主要异常大分类是
    Throwable
    ├── Error
    └── Exception
              └── RuntimeException
    NullPointerException, 这恐怕是一个最常见的异常，Java 对一个对象是否能为 null 值没什么约束，甚至用 null 来表示业务上的空。比如说方法的参数与返回值，Java 都可以是 null 值，而在 Kotlin 中非明确可为 null 的时不能为 null Read More

  • 《100 Java Mistakes and How to Avoid Them》笔记 2

    calendar Oct 25, 2023 · 5 min read · Java  ·
    Share on: linkedin copy
    《100 Java Mistakes and How to Avoid Them》笔记 2
    继续阅读本书，编程语言处理数值都有可能出现问题，如溢出，整数的最大最小值不对称，Double.NaN 等。


    由于 Java 学了 C，也用 0 开始的数字来表示 8 进制数，如 037, 010 分别是十进制的 31 和 8，这与现实不相符。因为如果你在纸上写下 037, 010, 几乎所有人(除了某些程序员)都会认为它们就是十进制的 37 和 10。但是 Java 表示 2 进制, 16 进制的方式没有问题的，如 0b10, 0x37。IntelliJ IDEA 看到使用 0 开头的 8 进制数会不建议那么使用. 8 进制数字的范围是 0~8, 所以 09 是错误的, 但是 Java 编译器似乎对此很陌生.

    int a = 09;

    IntelliJ IDEA 会提示 Integer number too large, 编译器提示说 java: ';' expected, 有点驴唇不对马嘴.

    现在几乎没有必要使用 0 开始的 8 进制数的方式, 或许还有用的就是表示 Unix 下文件权限, 如

    int fileMode = 0644

    所以任何时候看到 0 开头的数字都必须仔细检视, 基本可以禁止使用这种方式 Read More

  • 关于 JavaBean 规范你还是应该知道的二三事(补充)

    calendar Jul 2, 2009 · 1 min read · Java JavaBean  ·
    Share on: linkedin copy

    前面写过一篇： 关于 JavaBean 规范你还是应该知道的二三事 ，发现还略受关注。其中有人对 boolean 型属性的 getter/setter 方法还有些想法，以及 JavaBean 的规范是根据属性名找相应的 getter/setter 方法，还是由 getter/setter 定位属性呢。本文主要就这两问题展开话题，原本想附中前篇中去，但考虑会让前文凌乱，所以另立新篇。

    1. 关于 boolean  型属性

    分别来看看 Eclipse(3.5) 和 NetBean(6.7) 的重构功能对 oolean student 和 boolean isStudent 生成什么样的 getter/setter 方法的。 Read More

  • 关于 JavaBean 规范你还是应该知道的二三事

    calendar Jul 1, 2009 · 2 min read · Java JavaBean  ·
    Share on: linkedin copy
    作为 Java  程序员，对于 JavaBean 也许你会说再熟悉不过了，它贯穿在系统的多层中，不同的叫法有 PO、VO、DTO、POJO、DO(Domain Object)。然而它无外乎就是一个 Class 类，带上些属性和它们的 setter/getter 方法，set/get 后面那一个字母大写。虽然我们现在很少把 JavaBean 与那个古老的 2.0 的 EJB 搞混，但为什么明明用 IDE 为属性生成的 getter/setter 方法，应用一运行，还是报找不到某个 bean 属性的 setter 或 getter 方法呢？

    要知道，在 Sun 的网站上那个关于 JavaBean 规范的 PDF 文档可是有足足实实的 114 页啊。难免有些规则有点古怪，至使知名的 IDE 都难以应对，所以我们还是有必要了解其中二三，来规范我们的 JavaBean 和解释一些情形。

    Sun  的关于 JavaBean 规范见：http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html，其中可下载到 JavaBean 规范的  PDF 文档。 Read More

  • 有关于 JVM 的垃圾收集(三)

    calendar Apr 1, 2009 · 2 min read · Java JVM gc  ·
    Share on: linkedin copy
    对象可触及时的生命周期



    在 JVM 1.2 之前，堆中的对象分为三种状态，分别是：

    1. 可触及的 -- 从根节点开始可追踪到
    2. 可复活的 -- 从根节点开始追踪不到，但有可能被终结方法触及并复活。不仅仅是那些声明了 finalize() 方法的对象，而是所有的对象都要经过可复活状态
    3. 不可触及的 -- 以上两种可能性都不存在，可以真正回收它们所占据的内存了

    版本 1.2 中，可触及按强弱进一步细分为：

    1. 强可触及 -- 即原来的可触及，从根节点开始的任何直接引用，如一个局部变量或任何从强可触及对象的实例引用的对象
    2. 软可触及 -- 表现为 SoftReference 所引用的对象
    3. 弱可触及 -- 表现为 WeakReference 所引用的对象
    4. 影子可触及 -- 表现为 PhantomReference 所引用的对象 Read More

  • 有关于 JVM 的垃圾收集(二)

    calendar Dec 15, 2008 · 1 min read · Java JVM gc  ·
    Share on: linkedin copy

    自适应收集器

    在第一篇：有关于 JVM 的垃圾收集(一)  中谈到过几种垃圾收集的算法，然而我们的 JVM 启动之后并不要求彻头彻尾的死板的使用一种垃圾收集算法，固定的算法参数。因为某种情况下某些垃圾收集算法工作得更好，而别外一些收集算法在另外的情况下工作得更好，所以自适应的垃圾收集技术应运而生。自适应算法监视堆中的情形，并且对应的调整为合适的垃圾收集技术。或能是换一种垃圾收集算法，或者是调整当前算法参数，或者把堆划分为子堆，同时在不同的子堆中使用不同的算法。

    简述火车算法

    垃圾收集一般都会停止整个程序的运行来查找和收集垃圾对象，它们可能在程序执行的任意时刻暂停，并且暂停的时间也无法确定。垃圾收集也可能使得程序对事件响应迟钝，无法满足实时系统的要求。如果一种垃圾收集算法可能导致用户可察觉的到的停顿或者使得程序无法适合实时系统的要求，这种算法被称作破坏性。垃圾收集算法的还有一个基本目标是使本质上的破坏性尽可能少，如果可能的话，尽可能消除这种破坏性。 Read More

  • 有关于 JVM 的垃圾收集(一)

    calendar Oct 21, 2008 · 1 min read · Java JVM gc  ·
    Share on: linkedin copy

    Java 中使用 new、newarray、anewarray 和 multianewarray 指令来创建的对象，当这些对象不再使用时由垃圾收集来释放。 那么 反序列化等都是间接使用了前面的某个指令, clone()  是个本地方法？

    JVM 规范不需要任何特定的垃圾收集技术，甚至也没要求有垃圾收集机制。 大概只是说不需要手工释放内存，具体怎么实现各 JVM 自行决定。

    GC 除了释放不再被引用的对象，还要处理堆碎片， 整理出连续的空闲空间才能放得下新的对象。不至于出现总的空闲空间足够，但碎片太多而报出 "Out of Memory" 的异常。

    GC 有两个好处： 一个是提高了生产率，不用埋头于 Memory Link 的有时甚至是逐行的检查；二，GC 也是 Java 安全策略的一部分，有了它不至于因错误的释放内存而导至 JVM 崩溃。 但是 GC 的一个潜在缺陷影响了程序的性能，它需要一直在后台不时的做些事情，而且实时性也有所欠缺。 Read More