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

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

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

可以研究下 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 做了优化，当一个下标里的链表过长时，会自动转成红黑树。

你再看一下 putTreeVal 这个方法的源码呢。

@teawithlife 你看完我的 原理应该就会明白了。

我这套设计是 没有注册中心的，在整个微服务中，每个服务都需要向其余的所有服务发送心跳包，所以，在某个时间段，心跳包的消息数量会达到 n*n 条。 一旦微服务的机器扩大变多，这个压力还是需要重视的。

注：网络压力指的是内网压力

首先，你如果问的是把 sql 写在类里面 这种方式可不可取，那我个人认为把 sql 写类里面，和写 xml 里没啥区别， 现在都是 boot 打 jar 包，即使写在 xml 里 也是无法在线上更改的。

无论写哪，只要牵扯到改，都要程序员改完提测 然后重新打包发布，所以写类和写 xml 已经没有本质区别了。

所以，这种写法我个人认为完全没问题，不过肯定会有一些 盲目遵守规范的人 会说不行， 这个就不做争论了。。

其次，如果你问的这你贴出来的这段代码有没有问题，那么其他人已经都告诉你了，你需要让代码分布的更合理一点，然后参数不要拼接，要用占位符。

把 userForm 转成 json 字符串，String userFormStr = JSON.toJSONString(userForm);

然后判断 userFormStr 是否等于{}

@liuhan907 首先呢，我也是发布了这篇文章后才知道 gossip 这个名词的， 后来我专门去大致了解了一下。

发现 gossip 只是将数据传染出去，并没有心跳机制，他比较适合做 [分布式数据存储] 或者 [主从数据存储] 方案，在 redis cluster 里就借鉴了 gossip 的思想。

不过我这个方案 也可以说是借鉴了 gossip 的思想，谁让他比我早呢， 不过你说的不带优化，我是不承认的，我只承认目前这个方案确实不适合大规模的微服务，因为正如 [Sunmxt ] 大神所说， 在某个时间内，整个服务需要发送的消息数量能达到 n*n 。

不过这个并不是没有优化的结果，而是为了心跳机制，我目前能想到方案里，只有这个最稳定，只是有点耗带宽。

我后面的重点，也是想办法解决这个问题，东西嘛，都是慢慢试错试出来的。

@PiersSoCool 获取接口和发送广播的动作是 轮询的，不是一次性的。 数据会被慢慢纠正。

为什么要用轮询，主要是为了 心跳机制， 不然服务下线了 其他节点是不知道的。

不过这个心跳机制，造成了 在某个时间内，集群里要发送的 消息次数能达到 n*n，对网络会造成一定的压力，所以目前不太适合大规模的微服务。

这也是我下一步要 解决的问题。

你说的第 2 个点 我在给你耐心说一次：

你见过 mysql 主从吗？？ 主从连接是不是显式的配置了 ip ？？

你见过 zk 集群吗？ 是不是在配置文件里都配置了 其他节点的 ip ？

还有一点!!!!

这个配置的 ip 和 具体要调用的接口是两码事，两码事，你好好理解一下吧，什么都不懂，就大放厥词。

至于你说的安全性，我就更是哈哈哈哈了，如果黑客都攻击到你服务器上，反编译你的 jar 包去看配置了，还有安全性可言吗？？？ 如果他没攻上去，配置又怎么会暴露？？？

最后在给你说一次，这个 ip 和具体要调用的接口是两码事，两码事。调用接口不需要显式配置，不需要！！