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

多年不看春晚了。 如果非要看春晚，可以考虑翻出 80 年代的春晚再温习几次。 感觉可能是脱离了群众，所以群众不爱看了。都被娱乐轰炸一年了，最后一天都不放过。80 年代的小品等节目，感觉就是来源于真实的生活。都是大家都会遇到的东西，而且演员的功底，表达能力和现在的比比，答案自然就有了。很多话题在当时还真很辛辣的针砭时弊。目前…，是怎么样应该心里有数吧。 更牛的是各个节目之间还能互相串一下，这哪里是一台晚会，这明明就是一台戏，《宇宙牌香烟》，有没有。 现在的春晚越来越大气，布景越来越豪华，颜色越来越多，每年都是一堆人在上面狂奔，年年都是正能量，年年明天会更好，年年老百姓的日子比蜜甜，都被各个电视台的娱乐节目轰炸一年了，微博，头条，公号每一个都没有放过，演员出轨被刷屏，跳槽被刷 屏，节目咋地咋地又被刷屏。演员脸蛋越来越漂亮，但是就是看不出了味道。 可能是因为在舞台上演戏的和在生活上演戏的不再是一个维度了吧。 老百姓的日子过得怎么样，老百姓应该自己知道。 https://www.ossez.com/t/topic/13273 相信有不少人在为了信用卡和花呗在惆怅，也影响了心情。

需要大屏，顺便上来点分辨率就更好了。 一直是 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

Mutable object（可变对象） ：当对象被创建后，你可以修改对象的状态以及字段。例如 StringBuilder, java.util.Date Immutable object （不可变对象）：当对象被创建后，你不能修改对象的状态以及字段，例如包装类，如： Integer， Long，String 等。 绕的地方 当对象被创建后不能被改变？这个说法可能有点绕。其实说的是当对象被创建后就会一直在那里，如果你对对象进行调整，其实不是对老的对象的调整，其实等于你创建了一个新的对象，并对新的对象进行赋值。 Immutable 在 Spring 的 Autowired 注解中比较重要。在 Spring 的 Autowired 三种方式中，只有构造方法的 Autowired 是限制对象不能为 NULL 的，主要也是针对 Immutable 的问题。 实例 下面的代码来自 MIT 的教程，并且以比较常见的 Spring 和 StringBuffer and StringBuilder 为例子。 考察下面的代码： String s = "a"; s = s.concat("b"); // s+="b" and s=s+"b" also mean the same thing 官方的说法有点绕，上面的方法是我们常用的方法连接字符串。在第一步 String 创建对象的时候，我们赋值给对象 s。 在第二行代码，我们将对象 s 的后面再添加一个字符串。 在完成第二行代码后的 s 和 第一行代码的 s 不是同一个对象，等于 JVM 在第二行为你创建了一个新的对象并进行赋值。 StringBuilder sb = new StringBuilder("a"); sb.append("b"); 上面有关可变对象的 StringBuilder 的方法却完全不一样，在完成第一行和第二行后，sb 的这个对象没有改变。 一直都是 sb 这个对象，但是我们 sb 对象中的值改变了。 这就是很多人在编程的时候，会告诉你如果你需要使用 for 循环，或者是使用字符串拼接的时候，尽量使用 StringBuffer，在完成所有的 append 获得需要的字符串后，再使用 toString 转换为 String。 上面的小技巧的根源就在于可变对象或者不可变对象，通过这样可以避免在循环中过多的创建对象，因为在 JVM 中创建对象和销毁对象是占用资源的。 https://www.ossez.com/t/java-mutable-immutable/13265

Field injection is not recommended 警告的主要原因是：使用变量的依赖注入不被推荐。 @Autowired private REListingRepository reListingRepository; 可能很多人都会使用上面代码来进行依赖注入，因为上面的代码最简单，也是可以用的，但有时候你会遇到 IJ 的提示。     原因和处理 这个代码与 Spring 的 Autowired 3 种类注入依赖有关。 变量注入 上面的写法就是变量注入，这是我们遇到警告提示的地方。 Set 方法注入 为了避免上面的警告，我们可以使用 Set 方法来进行注入。 使用 Set 方法的代码如下： private REListingRepository reListingRepository; @Autowired public void setReListingRepository(REListingRepository reListingRepository) { this.reListingRepository = reListingRepository; } 构造器方法注入 另外的，我们还可以使用构造器的方法来进行注入。 上面的代码可以简化为： private REListingRepository reListingRepository; private TownRepository townRepository; @Autowired public TaxServiceImpl(REListingRepository reListingRepository, TownRepository townRepository) { this.reListingRepository = reListingRepository; this.townRepository = townRepository; } 的构造器方法来进行注入。 IJ 快捷键 在 IDEA 中是可以使用快捷键的。 在代码的空白地方，使用快捷键 Alt + Insert。 在弹出的对话框中，你可以看到为你生成构造方法和 Setter 方法的快捷键。 然后选择需要的生成相应的方法即可，而不需要你再手动敲一次。 使用何种依赖注入 我们现在知道了 Spring 有 3 中依赖注入方式。那么我们应该使用何种依赖注入方式？ 是使用： Constructor-based or setter-based DI 其实在官方里面已经有一个解释说明了：6. The IoC container 简单来说 Set 方法依赖注入中使用的依赖是可选的，选择依赖的意思是注入的依赖是可以为 NULL 的，当然你也可以在 Set 方法中通过添加 @Required 让依赖不为 NULL。 如果使用构造方法注入依赖的话，那么依赖是不能为 NULL 的。 变量方式注入应该尽量避免，使用set方式注入或者构造器注入，这两种方式的选择就要看这个类是强制依赖的话就用构造器方式，选择依赖的话就用set方法注入。 根据 Spring 官方的说法，如果注入的对象是 immutable objects （不可变对象）的话，依赖的注入是不能为 NULL 的。因此基于上面的示例和说法，Spring 官方是推荐使用构造方法来进行依赖注入，以便于针对不可变对象的注入。     唯一感觉不是非常好的就是代码比较长，看起来不太舒服。 不过使用 IEDA 可以在修改变量后重新使用快捷键生成构造方法。 https://www.ossez.com/t/spring-autowired-field-injection-is-not-recommended/13264/2