weixin_51954021的博客

本篇文章主要讲解如何在大流量高并发场景下进行估算和调优。 我们知道，垃圾回收器一般使用默认参数，就可以比较好的运行。但如果用错了某些参数，那么后果可能会比较严重，我不只一次看到有同学想要验证某个刚刚学到的优化参数，结果引起了线上 GC 的严重问题。 所以你的应用程序如果目前已经满足了需求，那就不要再随便动这些参数了。另外，优化代码获得的性能提升，远远大于参数调整所获得的性能提升，你不要纯粹为了调参数而走了弯路。 那么，GC 优化有没有可遵循的一些规则呢？这些“需求”又是指的什么？我们可以将目标归结为三

在分布式系统中，为保证同一时间只有一个客户端可以对共享资源进行操作，需要对共享资源加锁来实现，常见有三种方式： 基于数据库实现分布式锁 基于 Redis 实现分布式锁 基于 Zookeeper 实现分布式锁 高并发下数据库锁性能太差，本文不做探究。仅针对Redis 和 Zookeeper 实现的分布式锁进行分析。 实现一个分布式锁应该具备的特性： 高可用、高性能的获取锁与释放锁 在分布式系统环境下，一个方法或者变量同一时间只能被一个线程操作 具备锁失效机制，网络中断或宕机无法释放锁时，锁必须被