经历过几次硬盘损坏完全丢失数据后，痛定思痛，在 2019 年的时候上了个 NAS。 在上这个 NAS 的时候买了个 8 盘位的，顺便把手上的各种容量的硬盘都拿来装上了，所以硬盘的容量在 NAS 里面也是五花八门。 这样的配置通常不能够将容量用到最大化，但是好歹比单盘的要保险多了。 中途经历过一次硬盘损坏，换过一次硬盘升级过一次空间。 最近又有一块从老台式机上的硬盘被替换下来了，所以想着替换掉 NAS 中容量比较小的 500G 的硬盘。 扩充流程是： 更换硬盘 扩充存储池 扩充卷 必须要按照上面的顺序进行扩充，在扩充存储池的时候非常耗时，要有心理准备。 找到容量最小的盘位 首先要在你的 NAS 存储中，找到容量最小的盘位。 按照官方的推荐替换原则就是，为了保障存储空间的最大利用，你替换的新硬盘容量要大于等于 NAS 最大容量的硬盘，然后从 NAS 中容量最小的硬盘开始替换。 所以正确的打开姿势是，针对我的 NAS，需要最少容量是 6TB 的，并且从最小容量的盘位开始替换。 因为我这是用的老的台式机硬盘，一般来说替换的新硬盘大于你要替换的存储空间就 OK。 缺点是存储空间的提升很有限，不是你想的那样的算法。 下面的图显示的是，我们替换掉的第 6 盘位的硬盘，这块硬盘在没有替换之前和第8盘位的硬盘容量是一样的，都是 500 GB 替换下来后看了下老的硬盘，居然是 2007 年生产的，到现在已经有 14 年了，是有点老了。 修复存储池 替换硬盘后的下一步就是修复存储池。 当硬盘替换后，会提示你的存储池显示为降级，如果没有这个显示的话，你可以重启下你的 NAS。 然后在存储池上 Action 上会有一个提示为修复，单击修复就会弹出下面的界面。 在上面的界面中，NAS 已经告诉你识别到了新的硬盘和容量。 然后单击下一步继续。 下一步继续后如上图所示，你将会看到确定配置。在这个确定配置上面有一个总的容量。 这个容量就是在修复存储池后你的 NAS 将会扩展到的存储池容量。 确定后继续，然后你会看到 NAS 正在尝试帮你修复存储池。 这里的修复非常耗时，你可以准备 1 天的样子来完成。当上面正在修复的时候，你可以去休息休息了。 在修复的时候是不影响 NAS 使用的，你可以正常使用 NAS。 扩充卷 等第二天早上起来后再检查下你的 NAS 看看存储池是否已经修复成功了。 如果存储池已经修复成功了，你可以开始扩充卷来增加容量了。 下图是我们扩充卷之前的容量。 选择 Action 下面的 Configure 选项来进行配置。 因为我们扩充了存储池，所以我们可以在最大可用 GB 哪里看到了增加的容量，然后你单击 Max 进行最大容量扩充。 NAS 在这个时候会帮你扩充卷，这个扩充的过程很快，基本上几分钟就会完成。 在完成后，你便可以看到扩充完成的卷和大小了。 在完成上面的操作后，就可以享受到 NAS 扩充后的容量。 因为 NAS 具有上面的特性，因此较多盘位的 NAS 能够在保证不间断运行的时候扩充容量，同时针对单盘的数据备份要好得多得多。 硬盘有价，数据无价，再加上随着智能手机，摄像设备的使用，存储的需求越来越大。NAS 针对家庭和小型办公场所来说是一个不错的选择。 https://www.ossez.com/t/synology-nas/13286

在 IntelliJ IDEA 中可以通过快捷键和左侧的链接单击后查看当前类的方法结构。 Windows 的快捷键是 Ctrl + F12     当然，你还可以在编辑框中选择左侧的结构，同样也会显示方法的结构。     单击左侧就能够显示结构了。 通过显示类中方法的结构，我们就可以更加容易的在类中对方法进行搜索和查看。   https://www.ossez.com/t/intellij-idea/13283

抛开需求谈语言都是耍流氓。 Java 对数据处理，扩展，性能，在对大数据的时候都会比 PHP 要高一些。 现在的设计思路更多是前后端分离。其实前端工作量也不少的。 在开始想快速部署个PHP 项目可能更快，越到后面可能就越麻烦。 随着目前的前后端分离的思路越来越多的使用，一次性上 Java 不比 PHP 要大多少。 https://www.ossez.com/t/java-php/13282

在 Java 的线程安全是老生常谈的问题。经常是各种写法说法一大堆，感觉很多的来源都是在面试的时候，很多考官都喜欢问线程安全的问题。 起源 这个问题的起源就是 Java 是支持多线程的。如果对进程和线程是什么不太清楚的话，可以恶补下大学课程《操作系统》。 一般来说，JVM 是会以一个进程来运行，当进程启动后，会启动多个线程来提高 CPU 的利用率。 如果是多线程的话，那会在访问同一个变量，同一个代码的的时候出现数据不同步的情况。 简单来说对于一个变量 V，如果线程 TA 反问了，并且修改了，在这个时候，TB 线程也访问变量 V 也进行了修改。 在线程 TB 进行访问的和计算的时候，TB 不知道 TA 已经对 变量 V 进行了修改，会导致结果计算不准确。这是因为 TB 在拿到变量 V 的时候和 TA 在拿到变量 V 的时候的数据是不一样的。 这个就是线程安全的问题来源：线程同时访问了一个变量或者代码块。 思路 如果只是针对上面的思路的话，我们不定义全部变量 V 不就没有问题了。 事实上也是这样的，如果你定义的变量是线程内的变量，或者不可以修改的变量的话，是没有多线程的问题的。 因此考虑线程安全的问题，就是要考虑你定义的变量或者方法，在多个线程进行访问的和计算的时候会不会有不同的结果。 如果没有不同结果：线程安全。 有可能会得到不同的结果：线程不安全。 基于上面的说法，我们有多个办法可以参考下： 无状态实现（ stateless implementations）：没有使用全局变量，所有的变量都是方法内的变量。 不可变实现（ Immutable Implementations）：对象在创建后就不能被修改了。考察下 String 定义。 线程安全类（thread-safe classes）：类中的所有变量都会在本线程中使用，这个变量是不会与其他线程共享的，例如： private final 的 List。 同步（ Synchronized）：方法或者类或状态的同步，也可实现线程安全。 锁（Lock）：对锁的使用。 其实还有多种其他的方法来实现线程安全。 实际上在对 Java 的开发中，需要对线程安全的概念有所了解，并且知道查看 API 的时候需要了解会不会有线程安全的问题即可。 在实际的开发中，很多人就直接使用 Synchronized 关键字来实现方法的线程安全了。因为这个实现是最简单的。 可以看看 StringBuffer 的源代码也就会有所了解了。 https://www.ossez.com/t/java-thread-safety/13276

都是编译工具，各有各的优势。 貌似常用的几个大项目都将构建移到了 Gradle，例如 Hibernate，Spring。 相对来说也会增加不少 Gradle 的人气吧。 因为不怎么调整编译，很多时候感觉都差不多，但是 Gradle 的学习曲线确实比 Maven 要陡峭一点点。可以说是成也萧何败也萧何，Gradle 就是因为灵活性比 Maven 要好，所以开发插件，提供新的功能就要比 Maven 要容易。 同时 Gradle 也使用 Maven 的中央仓库，很多时候可以说是站在巨人的肩膀上面，在 Gradle 的设计时候就已经考虑过了 Maven 已经存在的一些问题。 就是因为 Gradle 设计灵活性又导致了学习起来难学习。 不太喜欢的是 Gradle 的包结构，当包下载下来后会打上标签，有时候都不知道包下哪里去了，Maven 这里比较直观，就直接能找到。 尤其是在调试的时候，希望能够删掉一个包，使用一个已经编译好的包替代下，直接拷贝过去就好了，使用 Gradle 在这里有点惆怅。 喜欢 Gradle 是，Gradle 比较容易出文档，其实这个问题也不是大问题，Gradle 可以直接编译 Asciidoctor 的文档，然后输出各种格式。 下载速度来说，一般大公司可能都会有 Central Maven 的镜像，感觉上差别不是非常多。 https://www.ossez.com/t/gradle-maven/13275

因为最近在研究线程安全和相关的可变对象和不可变对象的内容。 查看了下 StringBuffer 的源代码。 StringBuffer 的官方解释是，一个线程安全可变序列的字符串。StringBuffer 与 String 是一样的，但是是线程安全的。你可以在任何时候会存储一些字符串。有关 StringBuffer 的长度和存储的字符串，你可以使用 StringBuffer 提供的一些方法来进行修改。 StringBuffer 提供进行修改的这些方法是线程安全的。 StringBuffer 为一些方法进行了必要的同步来保证线程的安全。     通过源代码的查看，你可以明显的看到是使用 synchronized 关键字来通过线程同步来实现线程安全的。 StringBuilder 不是线程安全的，因为没有在代码中使用同步。     从对代码的研究就可以看出来 StringBuilder 是线程不安全的。可以根据需要在开发中使用。 https://www.ossez.com/t/java-stringbuffer/13271

需要大屏，顺便上来点分辨率就更好了。 一直是 23 寸的双屏幕，最近有个屏幕时间可能比较长了，有点闪了，在准备败一次。 考虑的 Dell，USB-C 供电，DP 可以桥接的屏。 桌上少点电线，看着心情好。 https://www.ossez.com/t/topic/13272

Happy Coding，好相处，无形之间解决麻烦。 程序员的水平高低没有绝对值，有学习能力的高低，有发现问题能力的强弱。大部分人是知其然不知其所以然，这个和个人没有太大关系，因为语言部分的变化太快，概念太多。 所以水平高低也只局限于在自己了解比较多的领域，很多人定义是给你一个语言，琢磨琢磨几个月能上手，写点代码，来点 debug，如果可以还能来点设计思路啥的，这就算不错了。     程序员其实永远不要把自己定义为自己就是程序员，如果你自己觉得你自己就是写代码的，那你可能在某个代码领域水平很好，但是其实缺失去了很多。 语言，代码就是为了解决生活中的问题的，解决企业需要的。 举个栗子：要求非常简单 CSV 数据导入数据库。 有些人喜欢玩花，搞个 Python 顺便来个数据分析，有些人就中规中矩 Core Java，有些人直接 OpenCSV + SQL，有些人干脆 SQL 工具，有些人 Spring Data，有些人 Hibernate，有些人 PHP，有些干脆做个 API。 上面的解决方案有错吗？其实都没有错，这个时候有些人会多嘴问一句，你数据量有多大，你需要导入多少次，需要做批量吗？就 10 万数据量，你随便写都没问题。如果几千万，上亿？这怎么办？ 数据是一次性导入又不是很大，无所谓了，随便写个Test 跑跑就 OK 了。 如果是多次调用，需要多次导入，需要容错，怎么设计呢？ 另外数据从哪里来？数据结构怎么样？有没有重复数据？有没有特殊字符？导入的目的是什么？可以有其他方案吗？ 如果能够比较准确理解需求，并且能够用语言，框架，工具提出解决方案，并且解决方案符合当前数据量和结构需求的，就是好的程序员；如果什么都不问，上手就哼哧哼哧写的，哪怕把很多高级特性都用出一朵花，可能都算不上是一个好程序员。 https://www.ossez.com/t/topic/13268

应该要明确一个问题就是在中国会赚钱的公司不一定是厉害和令人尊敬的公司。其实在外面也差不多，只是外面市场环境更好，你能做出好东西，养活自己有点发展的问题不大。     编程语言其实说白了也是计算机的一个工具罢了，你只需要使用编程语言来告诉计算机去做什么样的事情。 我们互联网公司的生态不好，公司不怎么鼓励员工的创新，当然这个现状也有一些改变了，比开始的时候好多了，只是要真正从语言开始确实还有很长很长的路要走。 一个语言的存在就是因为一些人对当前的环境不满，然后又找不到替代的方案，然后就自己闲着蛋疼鼓捣一个出来，自己鼓捣肯定没戏，然后就放到网上大家一起折腾，自己的东家公司也比较支持，你就倒腾吧。半年，一年下来，小样还真不错，那我们在一些项目中用用看。然后就继续改进，然后，然后就有了我们伟大互联网公司的拿来主义，帮着一起用。 然后的然后，一门语言就诞生了。 在这个流程中，你看看我们的公司缺了什么？ 我们的公司一直都是实用主义，不赚钱的基础研究我们一般不做，在中国的公司有想法，喜欢折腾的人都是另类，领导不喜欢，同事不待见。好不容易找个志同道合的可能开发个半年，发现食不果腹，还要奶孩子，真心没有办法玩呀，项目也就烂尾了。 一些项目放到网上，流言蜚语也一大堆，鼓励的少，BB 的多，生态不好。在这个时候谁有心思去研究那些东西，哪怕是别人把源代码都公开了，我们都还没有读透。 别说语言了，哪怕是 Spring 这个框架，有多少公司和人能真正深入的研究过。Spring 最早的来源就是大家对 EJB 的极度不满，臃肿的部署和开发，为什么我们没有想到再换个思维呢？ 与其他所有东西都一样，我们奉行拿来主义，没有创新的土壤，没有狂躁和狂野的内心，我们公司需要的是听话的 Worker，我们公司不需要真正的 Builder。 短期内看不到有这个方面的突破，这个不突破就难有自己的语言。 https://www.ossez.com/t/topic/13267

StringBuffer 和 StringBuilder 的存在是为了解决 String 对象的 immutable （不可变对象）的问题。 因此 StringBuffer 和 StringBuilder 都是可变对象，但是它们之间还是有一点点不同的，主要是在线程安全上面。     No. StringBuffer StringBuilder 1) StringBuffer 是同步的 可以说 StringBuffer 是线程安全的。 StringBuilder 是不同步的。因此 StringBuilder 是线程不安全的。 2) StringBuffer 比 StringBuilder 效率要低。 StringBuilder 的效率比 StringBuffer 更高 因为涉及到线程同步的问题，所以 StringBuffer 和 StringBuilder 的效率是有所差异的。 StringBuilder 是从 JDK 1.5 版本才添加进来的。 在进行字符串拼接或者对字符串涉及到一些操作的时候，可以尽量先使用 StringBuffer 和 StringBuilder 来构建字符串，然后再转换为 String 以提高效率。 因为 JVM 中的对象创建和销毁是需要资源的。 https://www.ossez.com/t/java-stringbuffer-stringbuilder/13266