百度云 mac 版客户端确实残废，一直都是这个样子的

虽然是二手的，但起码不是假的，总比某宝某猫全假货强

N+1 赔偿，每个人赔个几十万，值！

@esolve 基本都还在用 CMS，一方面是熟悉这个，另一方面我们的业务对停顿时间敏感，吞吐量的要求不是非常苛刻吞吐量需求只能排在第二位所以对于 G1 还在观望中

@esolve 一般都是先根据硬件情况大致测算出不同堆内存的 Full GC 的停顿时间，一般应用是不允许 GC 停顿超过 1.5 秒,否则就会影响上层业务，在 1.5 秒这个范畴内去设置合理的堆内存，一般硬件上也就三四个 G 的样子， 解决 STW 的问题主要还是靠单机多进程集群的方式，比如你有 32G 的内存可以分配给 JVM 进程，如果你把这些内存一次性分配给一个 JVM 进程，那么一旦产生 FULL GC,应用可能直接停顿半分钟以上甚至一分钟，这绝对是无法接受的，所以通常应该多起几个 JVM 进程，每个进程发生 FULL GC 的时候都要控制在 1.5 秒这个范畴内，这样才不会对上层业务产生影响，开 8 个 JVM 进程每个 4G 内存 1.5 秒 FULL GC 时间明显要比单个进程 32G 内存 1 分钟 FULL GC 好的多，我说的这些都是针对停顿时间敏感的业务比如高并发的 web 应用和 API 服务，如果对停顿时间不敏感也可以只开一个进程，比如后台跑算法啊批处理作业啊爬虫啊什么的就无所谓停顿多长时间了，因为即便是 FULL GC 一次十分钟，我们也是可以接受的

我想问一下，你们开这么大的堆内存，生产环境上有没有实际监控过一次 FULL GC 需要花费的时间呢，恐怕都得以分钟来计吧，难道你们的业务都不需要考虑 STW 的问题？还是除了常用的 CMS 和 G1 收集器外，你们手里还有更吊的垃圾收集器？

北京租房在回龙观，13 号线东可到朝阳区，西可到海淀区，搞 IT 的很多都在这儿

这个应该是金属擦亮膏吧，油管上有人用金属擦亮膏把涂层整个擦除的，屏幕直接变成镜面屏了，虽然可能会反光，但是也总脱落后的花屏好的多
https://www.youtube.com/watch?v=WBM3v35qr30

1、百度网盘能不能别乱建文件夹
2、百度网盘 MAC 版会员能不能别限制上传速度，MAC 上浏览器直接上传五六兆每秒，MAC 版客户端上传才一兆每秒，太不像话了
3、百度网盘 MAC 版赶紧把离线下载加上，半成品扔出来骗钱万年也不给更新
4、百度网盘 MAC 版客户端下载速度跟蜗牛一样，逼的我下载大文件只好用虚拟机里面的 Win 版客户端，什么时候才能让 MAC 版客户端速度跟 Win 版差不多啊，赶紧麻利儿的给更新啊
5、百度网盘 MAC 版客户端赶紧把资源 P2P 下载特性给加上啊，Win 版上大文件下载大部分都会转到 P2P 通道，怎么 MAC 上加个 P2P 加速特性就这么难产啊
。。。。。。。。
百度网盘 MAC 版客户端就是一个彻头彻尾的大骗子，明显是扔出来骗钱的，根本就是一个万年不给更新的半成品，太失望了，看看人家 MAC 版迅雷，虽然也是骗钱，起码人家核心的下载功能不是半成品啊，你这连个上传下载速度都控制不好，太 low 了点吧

同 2013 款，10.11.6 应该是最佳选择

颈椎没事儿，但是腰疼年年犯，

@micean 根据 Spring 官方文档来看，velocity 已死，
“ As of Spring Framework 4.3, Velocity support has been deprecated due to six years without active maintenance of the Apache Velocity project.”
https://docs.spring.io/spring/docs/4.3.13.RELEASE/spring-framework-reference/html/view.html#view-velocity

Freemarker 的话 Eclipse 不能很好支持，FreemarkerIDE 这个插件 JBoss 已经放弃开发了，只能做到语法高亮，内容辅助啥的全没有，如果你有钱买 IDEA 的话就推荐 Freemarker 了
Thymeleaf 想法挺好，但是性能差的一逼，谁用谁知道,如果你对性能不敏感就推荐这个了，虽然 Spring 强推这个但咱也要理性不是
JSP 就算了吧，页面默认允许随意书写 Java 代码，默认触发 Session 创建，表达式和 EL 输出变量默认不编码容易造成 XSS,CSRF 等问题，这都是硬伤啊，使用这个的话对人和代码规范的要求比较高，虽然可以从制度上约束，但还是不如从技术上就卡死的好，



竟然用手机打了这么多字，我也挺佩服我自己的，，，，

Zookeeper