同等，op 知道是哪款工具了吗。。。

能坚持到完成不半途而废就算非常成功了，OP 加油！

@Kisesy #3 老哥此言有理，这个库现在有俩维护者，我去找另一个维护者内部讨论下咋实现

@matrix1010 #4 老哥看得很透彻哇，是啊一些底层库可能用到的人很多，都基本都是比较靠上的用户层的库的依赖传递过来的，也不会有那么多人去看原理实现研究底层的实现，但是一旦出问题就会被疯狂抨击了。。。

多折腾多造轮子多写代码，没啥速成的法子吧，就是要多写唯手熟尔....

如果不知道写啥，我创建了一个组织专门用来造 Golang 的各种轮子练手，里面都是各种比较独立量级不大适合练手的 idea ，老哥有兴趣可以一起来撸代码，互相讨论技术方案、review 代码啥的：
https://github.com/golang-infrastructure

@songray 我也是这样子，想不清楚事的时候就出去走走，让冷风吹吹发昏的脑袋

@inzufu GitHub 在线编辑的功能就跳到 web 版本的 vscode 还可以用用，直接在 GitHub 主站编辑的那个编辑框真心难以驾驭....我比较多是用网页版在线看代码，它改版后读代码啥的体验感觉比之前好一些，但是 TimeLine 那个页面是真的有点用不明白。。。

活着，有饭吃，有觉睡，有代码写

@ryan4yin 是的我也注意到了，每次改版都得适应半天，这让我感觉到自己真的上年纪了。。。囧

@ryan4yin 我最近比较烦恼的一个问题就有点类似，是我 Go 项目分模块每个模块对应一个仓库托管在 GitHub ，然后模块发版比较频繁，就让 followers 看到非常多的发版信息，在 release 的时候还没办法隐藏动态。。。估计他们都烦的一笔。。。捂脸。。。

不提一下要求无不良编码习惯？哈哈哈

@CC11001100 补充一下，当时是一个开源项目，但是没有对外开放扩展 API ，为了扩展功能就自己想法子搞 API ，好像是 jadx 。。。不是破解商业项目。。。

通过这个命令把当前项目依赖的 jar 包拷贝到给定的目录：
`mvn dependency:copy-dependencies -DoutputDirectory=/directory/for/output/`
打包发送给同事，他接收后解压加到项目的依赖中，然后使用这个工具挑拣出中央仓库有的和仅在本地有的，生成自己的 pom.xml 文件：
[https://github.com/java-sec/jar-finder]( https://github.com/java-sec/jar-finder)
最后把项目跑起来。。。当时写这个工具的场景跟 op 有点类似，是在逆别人发布的项目的依赖...

@Kumo31 老哥牛皮，看描述感觉这个就是我苦苦寻找的算法，给跪了我去搜搜资料学习学习，非常感谢！

@chesha1 惭愧工作多年很多基础的东西还是不太清楚，书上的东西老是领悟不透彻时常踩坑摸索。

直接看帖子是会觉得这是奇奇怪怪的想法哈哈哈，这件事的来龙去脉是这样，去年底的时候 op 参与过某个 client 端的项目，里面有个业务点是会涉及到多个角色用纯 client 端软件协同操作数据库，当时负责这块的同事没处理到这种并发情况出了几次事故，op 插进来紧急救火撸了个基于 postgresql 数据库的分布式锁，当时是以 Redis 的分布式的思路为基础修改出了 postgresql 的分布式锁，从那就开始业余时间偶尔关注这块。

后来又想这个能不能推广开来，然后就实现了通用的关系型数据库分布式锁。

再后来又想，一定要是关系型数据库吗？ kv 数据库呢？当时关系型数据库的通用的锁是使用基于 CAS 的带版本的乐观锁实现的，但是如果是 kv 数据库的话就只有 set/get 操作没想明白，于是就有了这篇帖子。。。

@CC11001100 如果上面这个论述是成立的，那靠 set 和 get 似乎是真的不能构造出锁，怎么组合也不行，毕竟无法凭空产生互斥特性，这就令人沮丧了毕竟我都琢磨了好几天了。。。o(╥﹏╥)o

@CC11001100 互斥特性比如 CAS 、比如某个 mutex 变量之类的

@hxysnail @chesha1 @krapnik 是的我之前跟朋友讨论的时候也突然领悟到一个点当时还跟他说来着，上面帖子描述没说是因为我也不知道悟得对不对，就是所谓的锁其实就是在某个互斥特性的基础上施加一些操作构造出来更复杂的操作，但是基础是必须要有一个互斥特性否则就没办法构造出锁，锁不能凭空生成必须要有互斥基础，锁或者分布式锁也只是对互斥特性的作用域进行放大，其本质特性还是最底下的那一个互斥特性

@Akitora 是的，如果有已经存在的原子、互斥操作的话可以基于这个操作很方便扩展出来锁