git push origin 分支名称。

解压，修改，压缩，改后缀

有点不明白，既然是测试，为什么要乱填号码？ 乱填以后，你怎么知道短信验证码有没有发出去呢？ 流程都无法闭环了。

navicat 不香吗

ctrl + c 退出当前进程。

人的动作，是单进程的。 即使你弄出来了这东西，你同一时间也只能做一个动作。

不信？ 你仔细注意下，当你操作鼠标的时候，左手是不是停下来了。 当你按快捷键的时候，右手是不是停下来了。

你发这个帖子的 专区，是不是就是你说的这种平台？

最佳的地点是，想去哪去哪。不固定

怕吵的人，睡觉前会把手机静音的。

可以研究下 ios 的 app 管理机制。

关注几个高质量的微信公众号，完美解决。

@levizheng

首先第一段，单例对象一旦实例化后，就会一直存在，你说饿汉模式占用资源，其实只是在一开始占用的比懒汉多，但是随着项目的运行，所有懒汉都将被实例化，最终占用的资源都是一样的

volatile 这个 我说的可能不对吧，谢谢你的指点，我再去深入学一下。

至于最后一段，我是在解释，同步锁不是为了防止获取 null 值，而是为了防止获取多个对象， 我并不是按照他的代码来说的。

没有什么必要不必要的， 买东西遵循两个原则：

1. 买可以满足自己需求的东西
2. 在第一条的基础上，看看自己的钱包，决定要不要买更好的

首先呢，同步不是为了防止获取 null 值，你都 if （ xxx=null ）了，还怎么可能返回 null 呢？ 同步是为了防止获取多个实例。

比如项目刚启动，这个单例还没被实例化，此时两个并发过来了。

比如 A 和 B 同时调用了 getXX 方法， 当 A 进入了 if 以后，在执行 xxx = new XXX(); 之前，B 进来了，此时 xxx 还是空的吧？

那么 B 也会进入 if 对不对？

此时 A 执行了 xxx = new XXX(); 并返回了，B 才开始执行 xxx = new XXX();

A 和 B 是不是获取到的对象不一样？ 那这就不是单例了啊。

所以必须等 A 拿到了返回值，B 才能进来，所以才用同步锁。

-----------------------------------------------

然后就是你的问题了，在锁释放之前，其他线程是无法执行这一段代码的，这才是它的意义。 至于你说的释放前会不会同步到主内存，那肯定是不会的，但是如果你加了 volatile 就会同步。

最后，你这段代码有点过于复杂了，直接在 getUniqueInstance 方法上加个锁不就好了。其他的都可以删掉了。
或者你干脆 用饱汉模式，private static Singleton uniqueInstance = new Singleton(); 在 getUniqueInstance 方法里直接 return 就好了，都不需要锁。这种支持并发，效率高一些。

war 包直接解压就好啦， 改完后在 压缩车 zip，然后改下后缀即可。

不过 war 里面都是字节码啊，，你改源码是什么操作。

指令肯定是有限的，不可能无限吧。 你可以维护一套指令集， 后面每次前端给你下发指令的时候，就去指令集里查找对应的编码，然后执行。 找不到 的时候还可以给前端一个友好提示，此指令不存在。

@GM
首先不同的对象，hashcode 可能会一样，这就导致了 你 put 两个不同的 key 可能 hashcode 一样，造成存到同一个下标里。 但是你明明 put 的是两个不同的 key，总不能直接覆盖吧，所以 才有了数组+链表的 数据结构，就是当 hash 碰撞时，在同一个下标里 把两个值存进去。 但是也不能直接追加吧，所以需要循环这个链表，判断 hasncode 和值是否都跟你 put 进来的这个 key 相等，如果相等就覆盖 value，不相等才追加。


现在 hashmap 做了优化，当一个下标里的链表过长时，会自动转成红黑树。