2022年9月

本文谈论的clean code要求并不高(常规水平)，我觉得对于日常开发来说能达到:

  • 变量命名清晰简洁、
  • 函数功能较为单一，逻辑清晰，能复用的情况下做到不同函数职责设计合理
  • 简单场景能简单用到常用设计模式
  • ...

以上这些能做到,写出的代码就已经算得上是中上水平了(不要求用一些高阶方法或者什么巧妙方法，甚至没有完整看过代码整洁之道或者重构这种书籍也可以,能正常写整洁代码就可以了),对此有的公司可能要求会更高。

类似于写字，不要求每个人都能写出非常漂亮的字，至少看起来要工整这个要求并不过分。

- 阅读剩余部分 -

为什么推荐优先使用char[]/byte[]存储敏感信息

  1. 字符串变量是不可变的。一旦分配了字符串变量，就无法更改或删除其值。因此，这些字符串可能在可能在多个位置的存储器中保持不变，持续一段时间，直到垃圾收集器正好将其移除，且由于字符串是不可变的，所以没有任何方式可以修改字符串的值，因为每次修改都将产生新的字符串。敏感数据（如密码）将作为明文在内存中暴露，无法控制其生命周期因为任何能够访问内存(memory dump内存转储)的人都能清晰的看到文本中的密码，这也是为什么你应该总是使用加密的形式而不是明文来保存密码。因为String使用常量池存储字符串，即使jdk7之后常量池移到了堆，也要在触发gc之后才能彻底清除掉内存中的敏感信息。
  2. Java官方文档《Java加密体系结构指南》 (https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#PBEEx) 建议：在对象java.lang.String 中收集和存储密码看似符合逻辑，但是需要注意的是，字符串对象是不可变的，没有任何方法可以改变（重写）或清空内容。这一特性使得字符串对象不适合存储安全敏感信息，比如用户密码。你应该使用字符数组收集和存储安全敏感信息。
  3. 建议使用专用类存储明文的敏感信息，或者，将明文敏感信息临时存储在可变数据类型（如：char[]/byte[]）中，且用完后立即擦除。如果没有及时清空而由GC来清除的话，暴露窗口大约是秒这个数量级，如果能够在计算HASH后立即清除，暴露窗口大约是微秒数量级。如此简单的设计就可以降低如此多的被攻击概率，性价比是非常高的。
  4. 其他问题：通过reflection机制可以查看String的内部的内存成员，从而可以直接修改其中的数据区。但是这样的做法会有问题，内部化的String为了提高HASH速度，节省空间，值相同的字符串通常只有一个实例。
    你自己的char[]，修改它是没有副作用的。但是String里的char[]，很可能是多个String所共享的，你改掉它就会殃及别的String。举个例子，有一个密码是"Password"，而你密码框提示密码输入的文字也是"Password"，改掉第一个"Password"会把后面那个也改掉。

- 阅读剩余部分 -

ConcurrentModificationException引起的问题

现象

这是一个由ConcurrentModificationException引发的问题，先看下这段程序:

List<String> tmpList1 = new LinkedList<>();
tmpList1.add("Hello");
tmpList1.add("My");
tmpList1.add("Son");

for (String curStr : tmpList1) {
    if ("My".equals(curStr)) {
        tmpList1.remove(curStr);
    }
    System.out.printf("curStr = %s, tmpList = %s\n", curStr, tmpList1.toString());
}

- 阅读剩余部分 -

如果不小心在本地把某个本地分支A以及远端分支origin/A都删了的话...

目前可用的方法

  1. 比较可靠的方式：问下其他人本地有没有代码，idea会自动fetch，所以有比较大的可能性能找到分支A的较新状态，可以请他重新推到远端(其他git工具也有可能)。
  2. 远端分支还在的话可以考虑重新拉下来，如果本地没有额外提交的话
  3. 用git恢复分支，这种方法可行但是不一定能完全恢复

- 阅读剩余部分 -

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5