@sujin190 是的，有 64 位的原子操作。之所以要强制对齐，原因是在 32 位平台下进行 64 位原子操作要求必须 8 字节对齐，否则程序会崩溃。这个在 1 楼贴出的文档里描述了，实际测试起来也确实是这样。

@icexin 注释我是看明白了是为了让 Stats 对齐，但是不明白的地方是为什么非要让它对齐，如果不对齐的话不是可以更加节省内存吗？ 看了你贴的链接就明白了，十分感谢解答！！

最终都是要让 node 可解释的，所以想要不被破解是不可能的，只能说增加难度，目前我们的做法是用 webpack+uglifyjs 做压缩和混淆，然后再用 pkg 包装一层。

一直用的 SSD 的移动硬盘，工作用的系统和开发环境都装里面，速度还是可以的。

@metrxqin 这种和业务强相关的情况不赞成发明一些新的名词来作解释，量是一个问题，更关键的是无法直接体现出业务方面的东西，而对于后续的维护、扩展来说，如果一个变量 /字段 的业务相关性不够清晰明了的话，会需要花更多的时间来明确，甚至可能到最后都弄错了，而且随着时间的的推移、人员的替换，出现错误的概率会不断升高。

@realpg 这种强业务性的东西，如果全用英文来表达的话，过段时间自己可能就看不懂了，更何况是以后维护换个人来看。所以还是需要具体问题具体分析，不推荐使用中文，但是必要的时候该用还是得用。

不支持中文命名，但是在业务性强的系统中，对于实体类和一些常量(仅限实体类、常量)还是推荐使用的，否则很多名词用英语很难表达清楚，关键是换个人来看这代码，看到统一串英文不一定能和中文环境下的名次对上号。
比如我们开发的一个系统中，有大量这样的名词：
1. 决定判决情况
2. 判决情况
3. 历次减刑情况
4. 刑罚执行检查档案审查情况
...
这些字段和其他系统是直接相关的(我们这个是辅助系统), 而且随着这个系统支持的业务范围不断的扩大，如果全都使用英文(缩写)，维护起来简直就是灾难。

@wmhx 确实是，盗版这么流行不是没原因的

@IvanLi127 然后就等着坐牢了…

@lastpass 哈哈哈哈是这样的没错，所以我们这个不带数据库的哈，除了日志文件，其他的不能记录任何客户的信息，导出日志都需要审核，我们的产品是工具类的

@lihongming 这个方案也好，而且可以较好地结合其他楼主的方案，受教了，十分感谢！

@wenzhoou 那么假设确认这个文件存在性、是否被篡改及机器信息匹配的函数（或者多个函数）被反编译后，对方根据反编译得到的代码编译出一个总是返回验证通过的版本的 class 替换掉了原来的 class 文件，这种情况也还是无法解决了，毕竟 java 的字节码和源码差不了太多。。

@PHPer233 目前正在考虑类似的方案，可能目前比较好的方法就是混淆+自主加密算法+10 楼的方案吧

@anotherlf 哈哈哈产品是涉密的，不能开源、不能接 U 盘，包括日志文件都必须经过审核才能拿出来的

@pabupa JB 是网上有现成的 licence 可以用，所以别人就不需要去做破解版了，还有就是 JB 的授权服务器也被破解了，可以自己搭建的

@ahhui 对的，这个是我的错误。主要的问题都不在于 licence 里面是什么，licence 怎么生成的，真正的问题在于只要是（在我的理解范围内的只要是）纯 java 实现的，都可以比较轻易的通过反编译得到对应的验证逻辑，然后替换 class 文件实现破解，正如 25 楼说的这样= =

@cxh116 也是，如果有完全的离线授权方案的话也不会有那么多盗版软件了。。。

@likuku 唉，可惜环境不允许