这个问题在 Java 面试的时候大概率会被问到。 不是因为这个问题有什么复杂的，只是因为这个地方超出人类认知，你相信吗？ 比较什么 如果你上培训班或者在学校学习的话，你的老师大概率可能会告诉你对于： 基本类型：比较的是值是否相同； 引用类型：比较的是引用是否相同； 本来这里就有点复杂了，还非要搞出另外 2 个概念。 比较好记的就是 == 比较的是内存地址，equals 比较的是具体的值。 对上面的问题，所谓的基本类型，因为没有对象话，所以 JVM 没有为基本类型创建实例化后的对象，因此 == 就可以直接用了，因为 2 个相同的基本类型的值的地址是一样的。 String 为什么不行 String 在 Java 里面有点奇葩，因为 String 是在是用得太多了。 所以 Java 为 String 搞了一个 String Pool，对于程序中，你这样定义的字符 String s1 = "iSharkFly"；这个数据是存储在 String Pool 里面的。 因为 String 在 Java 里面被定义为不可变。等下一次你定义一个 s2 的时候，如果是同样的值， s1 和 s2 是相同的，因为都在 String Pool 里面。 String 还有另外一个初始化方法：` String s1 = new String(“iSharkFly”); 这个方法初始化的 String 是一个对象，这个对象没有放在 String Pool 里面，这个对象在 Heap 内存中。 所以： String s1 = new String("iSharkFly"); String s2 = new String("iSharkFly"); 的内存地址是不相同的，但是值相同。 使用 == 比较，上面就没有办法比较。 查看下面的代码： String s1 = new String("iSharkFly"); String s2 = new String("iSharkFly"); log.debug("hashCode - {}", s1.hashCode()); log.debug("hashCode- {}", s2.hashCode()); log.debug("identityHashCode- {}", System.identityHashCode(s1)); log.debug("identityHashCode - {}", System.identityHashCode(s2)); 程序输出： 我们会看到地址是不相同的。 hashCode 都知道 hashCode 会返回对象的 HashCode 来识别对象，为什么上面的地址是一样的？ 因为 hashCode 会在程序中被重写。 下面的是 String 的 HashCode 代码。 JDK 已经对代码进行了重写。所以 hashCode 并不能完全标识内存地址。 所以，我们只能使用 System.identityHashCode 方法来获得内存地址。 总结 equals 和 == 在 Java 面试中经常会遇到。 只需要记住的是 == 比较的是内存地址，在对值进行比较的时候并不可靠。 在实际编码过程中，这种比较也比较常见的，所以还是有必要了解下这个。 https://www.isharkfly.com/t/java-equals/14839
如你对 Abstract 修饰的抽象类不是非常了解的话，请自行先考古下。 这篇文章需要对 Java 定义过的抽象类有一些基本的了解才可以。 抽象类和抽象方法 用 Abstract 修饰的类，叫做抽象类，那么用 Abstract 修饰的方法叫做抽象方法。 在 Java 中，喜欢用一些修饰关键字来对类或者变量或者方法来进行修饰。修饰的目的是更加明确一些类或者方法，或者变量的使用。 可以简单的理解为，使用关键字来修饰过的东西用来限制使用范围而已。 关于抽象类和抽象方法： 用 abstract 修饰过的方法所在的类一定是抽象类。 用 abstract 修饰过的类，不一定有抽象方法。 什么是接口 和 abstract 修饰过的类比起来，接口是用 interface 来修饰的，这个是在用 abstract 修饰的类上面进行进一步的限制和简化。 而接口中只能存在 public abstract 方法。 用很多人常使用的定义，接口就就是类似墙上的电源插头，上面定义了某个方法，然后让别人去实现的。 打个不是否恰当的比喻，为了从接口中获得电力，你管这个电力是火电还是核电。 正是因为这样的关系，所有接口中定义的方法必须要有实现。 一个类可以实现多个接口，但接口中定义的所有方法必须全部要实现。 接口中的变量会被隐式地指定为 public static final 变量（并且只能是 public static final变量，用 private 修饰会报编译错误），而方法会被隐式地指定为 public abstract 方法且只能是 public abstract 方法（用其他关键字，比如 private、protected、static、 final 等修饰会报编译错误）。 接口和抽象类的关系 首先可以理解为 interface 就是 abstract 的一个子集，内容和信息比 abstract 更加精简。 interface 中的方法是用来实现的，abstract 中的方法是用来继承的，这 2 个用途不一样。 因为 abstract 不能实例化，那么 interface 也肯定不能实例化了。 实际使用 举个实际使用的例子，我们现在有一个这样的需求，发送一个 HTTP 请求，获得用户的数据。 当我们希望对这个进行实现的时候，我们可以使用 apache 的 httpclient 这个包来完成 http 的调用，我们也可以使用 OKHttp 这个包来实现 http 的调用。 为了定义大家都使用的方法，我们就在这 2 个调用之前，定义了一个接口来要求我们的 2 个子类分别使用不同的包来实现完成调用返回结果。 小问题 如这里，我们只有一个实现，还有必要定义接口吗？ 这个问题问得就非常好，如果你真只有一个实现的话，定义接口就纯粹属于脱了裤子放屁了。 当然你是可以定义的，只是定义的接口没有什么太大的意义，因为你就使用了这一个实现，何必再增加一个类搞得程序难读，直接使用实现类就好了。 总结 接口在 Java 中非常常用，但实际使用上，用不好会增加复杂性和没有必要的程序设计。 在日常开发中，大部分公司可能会选择用 Spring 框架。 单例 是Spring 当中bean 的默认范围(Scope)。Spring 容器会为某个bean 定义对象创建唯一的实例。 对于一般公司在初期可能更多的是关注业务实现，他们并不在意使用某种类实现，比如说上面的实现的 http 调用，可能就用了 OkHttp 实现就好了。 抽象出来各种接口，其实比较麻烦，软件开发的同事基本上就不写接口了。 这也导致了在你的软件项目中，看到接口的地方越来越少了。因为等于要多写一个类，同时还在这个类中写了不同的限制方法，如果我要加一个方法在接口中，所有的实现类都要加。 如果开始就设计不好的话，要加方法还挺繁琐。 在 IntelliJ IDEA 中，可以单击接口签名的 I 标记来看看有多少类实现了这个接口。 所以，有关接口的定义，目前更多用在很多八股文的面试题中，有些所谓的架构师会问下你接口是干什么的，很多情况下可能他们自己都已经不写接口了。 https://www.isharkfly.com/t/java-abstract-interface/14838
有个花坛也就算是边境了，可以说一个不太正经的边境吧。 当然也不会是想象中的那么容易就过去的了，通常在美加边境都有不少的 CBP 边境巡逻车。 对没有合理证件入境的，估计也不一定有什么好的脸色。 在边境边上找了好几年前来过的一家餐馆了解决下午饭的问题。 感觉上又发现了一个宝藏牛排。 通常牛排都是烤的多，这次却意外的有机会尝试了下用水烤的牛排，也感觉上是别有一番风味。 和朋友相约，下次再来。 https://www.isharkfly.com/t/topic/14753
短回答就是：不能 这里有 2 个概念，什么是抽象类和什么是实例化。 实例化 实例化简单来说就是为 Java 中使用的对象分配存储空间。 抽象类 从代码上来说，抽象类就是一个用 abstract 关键字来修饰的类。 这个类除了不能被实例化以外，其他都能做。 在面向对象的概念中，所有的对象都是通过类来描绘的，但是反过来，并不是所有的类都是用来描绘对象的，如果一个类中没有包含足够的信息来描绘一个具体的对象，这样的类就是抽象类。 抽象类除了不能实例化对象之外，类的其它功能依然存在，成员变量、成员方法和构造方法的访问方式和普通类一样。 // Java program to demonstrate abstract class // cannot have instance public abstract class ClassOne { public void printSomething() { System.out.println("Hello in abstract class"); } } class CreateClassOne { public static void main(String[] args) { // instance of abstract // class "ClassOne" ClassOne obj = new ClassOne(); } } 上面的代码运行时候将会出现错误： prog.java:17: error: ClassOne is abstract; cannot be instantiated ClassOne obj = new ClassOne(); ^ 1 error 因为你尝试实例化这个抽象类。 为什么不能实例化抽象类 很多人在这里都有点懵，为什么我就不能实例化抽象类。 正如我们上面说的，实例化就是为类分配需要的内容空间，以便于类去进行计算。 因为抽象类没有足够的信息， JVM 没有办法知道抽象类到底给他们分配什么。比如说没有具体的成员变量和成员方法。 你说，我们可以这样呀： HashMap hashMap = new HashMap(); AbstractMap abstractMap = new TreeMap(); 这样是对 abstractMap 进行实例化吗？这显然不是。 这是你用抽象类的名字定义了一个 Map，但是这个 Map 是用 TreeMap 实例化的。 最后你内存里面得到的是一个 TreeMap 而不是 abstractMap。 https://www.isharkfly.com/t/java/14751
冬季开始之前就是各种收拾装备的时间了。 对滑雪这个项目来说，是一个装备比较多的项目，所以在每年的训练季或者说是滑雪季开始之前，各种展会就开始了。 通常这种小展会的规模并不是很大，多是在具体的滑雪场举办。 https://www.isharkfly.com/t/topic/14752
3 天前，运行的社区系统报告，很多老的历史照片都无法作为附件加载 —— 小鲨鱼，快来解决问题。 很多人都问题，为什么程序员每天不是在调 Bug 就是在调 Bug 的路上。 其实呀，计算机是一个逻辑性非常强的东西，每一步都应该是原因的，所以我们要通过逻辑性找到不同的原因。 这个和把大象关进笼子里有几步差不多。 调试的方法其实就是针对问题去找到原因，为什么会出现这个问题。 对 Web 系统来说，无非就是程序和数据，首先需要确定数据丢了没有，如果数据丢了，怎么调试都没有用，因此先恢复数据，保障系统运行永远是第一位的。 Step 1 有没有快速的解决方案 为什么会出现这个问题，不是好好的吗？原来是因为更换了域名，同时更换了云存储的存储路径。 现在问题就是主题中的内容都没有丢，但是当主题重新生成 HTML 后，只要主题中有附件的部分，全部都没有正确生成 HTML。 快点检查存储在云端的附件有没有被删掉。找到一个老的主题已经生成的 HTML，然后检查丢失的图片对比的服务器地址。 云存储的附件都还在，没有被丢掉，如果直接把绝对 URL 拷贝过来，问题就解决了。 赶紧的，有备份吗？ 有备份，赶快恢复一次。 Step 2 数据恢复 恢复备份后无法解决问题。 备份恢复了，问题依旧。怎么办？ 有多少主题被影响到？ 往前面找 3 个月，1 个月，2 个星期的随机帖子，貌似各种情况都有，但是大量丢的都在 几个星期之前的，几乎都无法显示。 那应该是在生成 HTML 的短 Hash 代码转码回去的时候出现问题了。 这个数量已经非常大了，没有办法通过手工恢复的方式完成了。 这里有个判断，如果只影响到几个主题，通常我们都可以手工恢复的，如果影响的主题超过几十个，这个时候是没有办法手工恢复，只能找到原因让程序去做了。 Step 3 调试存储桶路径 因为我们知道存储桶路径换了，是不是因为存储桶的名字问题呢？ 把服务器上存储桶的名字重新改回来，问题依旧。 现在这个和存储桶的路径应该没有太大的关系。 Step 4 调试 Hash 算法 是不是因为在 Base 62 Hash 算法的时候因为 SHA1 的不同而导致了算法没有被正常解码？ 读了下程序，貌似问题也不在这里。 这个 Base62 算法，程序中没有加摘要扰乱计算。 Step 5 查询数据库的数据 现在我们得从数据库查看了，因为没有办法确定到底是程序还是数据的问题。 貌似在备份前 3 天的数据是好的，我们应该要把数据库的数据恢复下看看。 服务器现在在运行的，好在新加的主题没有问题，那就让服务器运行着吧。 我们把服务器上的数据 Dump 下来，导入到我们本地的 PGSQL 数据库中吧。 这个导入过程可能要一天也可能是几个小时，因为导入数据比较容易出错。 Step 6 如何进入服务器 Docker 容器内查询 数据本地拿到了，Hash 前的和 Hash 后的数据都在呀，那问题在哪呢？ 到 Docker 容器内去查询下现有的服务器数据吧。 这个时候，你就可能需要时间去了解下如何进入 Docker，如何在 Docker 连接数据库后运行 SQL。 因为这个库是在容器内的，你是没有办法通过其他数据库工具直接连接到数据库上运行 SQL 的，通常生成服务器也不允许你这么做。 查询的结果，发现是本地有的记录，服务器上没有。 大概率知道数据库映射出了问题。 Step 7 把本地的备份数据恢复 1 条 把本地备份的 1 条数据恢复到服务器上，然后刷下效果，看是不是就是因为数据丢了？ 太棒了，恢复的这条数据被显示出来了，主题正常了。 原来就是丢数据了，备份不应该是备份全部的吗？看来应该是恢复哪里或者某个表出问题了。 Step 8 获得具体有多少数据被影响 因为我们知道那个表现在有问题了， Select Count(*) 呗。 发现一共了 4000 多条记录被影响。 赶紧把本地的这些记录组织成 SQL 到服务器上运行吧，都是 Insert 应该问题大。哪怕是重复数据，因为有 Key，重复数据会被忽略掉。 导入后问题解决了。 Step 9 解决问题后 2 天同样的问题又出现了 先查 Count，后来发现 Count 数据被删掉了 2000 多。 这肯定是有自动运行进程对数据进行清理了。 上网考古下，发现貌似有一个无用附件清理进程会对程序认为无用的附件进行清理。 先不管了，把这 2000 多条数据恢复再说。 Step 10 关闭清理进程 先关闭清理进程，然后看为什么这个程序会把我们实际是需要的数据给清理掉？ 读代码，在清理之前，程序会判断那些数据是需要清理的，这里有一个 Join 的 SQL 查询。 这里 Join 了另外一个表。 Step 11 对比 JOIN 表数据量 马上对比另外表的数据量。 这里了明显又丢了好几千条记录。 原来在主题和附件的关系映射表中的数据丢了部分，导致整个附件表的有用数据被当做无效数据清理掉了。 Step 12 数据恢复 把 JOIN 的映射表数据进行恢复。 然后等待重构运行结果，保持清理进程开启，2 天后查看结果。 同时增加服务器备份数量，从保留 30 天的备份，到现在增加到保留 300 天。 Step 13 问题总结和记录 把整个过程总结下来，花个 10 多分钟记录下问题。 上面是针对一个问题进行调试的小过程，如果你对系统比较熟悉的话，很快就会定位到映射部分。如果对系统不熟悉的话，上面的步骤就是一个几乎完整的 Debug 流程。 在上面的流程中到处都是坑，这就是为什么有些人看起来只需要几个小时或者几分钟就解决问题了，你却用了几天的时候，甚至几天都没有进展。 相信我，不是因为你不够优秀，仅仅是因为你对已有的这套系统的设计，数据，逻辑不熟悉而已，这没什么大不了的，时间问题。 https://www.isharkfly.com/t/topic/14724
群晖（Synology）NAS 的后台在新版本对 Docker 不再称为 Docker，现在改称为 Container Manager 了。 单击进入后运行 Container Manager。 PostgreSQL 容器 针对 PostgreSQL 的容器，我们选择容器后，如果你已经安装了 PostgreSQL 的话，应该就能看到运行的容器了。 然后选择设置。 在 PostgreSQL 的容器设置中有 2 个参数比较重要。 端口 第一个是 PostgreSQL 的端口，默认是 5432，但是不知道为什么我的 NAS 提示 5432 端口被占用了。 所以我还必须使用另外端口来进行映射。 我选择的端口是 5433 来进行映射。 在局域网中，我们需要端口 5433 来链接运行在 5422 的 PostgreSQL 服务。 环境变量 另外一个重要的环境变量是 POSTGRES_PASSWORD，这个是连接 PostgreSQL 的默认密码。 如果这个变量不设置的话，PostgreSQL 容器是没有办法启动的。 当上面的 2 个参数被设置好以后，PostgreSQL 容器应该可以运行的了。 然后使用 pgAdmin 进行连接测试。 https://www.isharkfly.com/t/synology-nas-docker-postgresql/14719
最近我们有一个 SQL 需要导入到 PostgreSQL ，但数据格式使用的是用： -- -- TOC entry 7877 (class 0 OID 21961) -- Dependencies: 904 -- Data for Name: upload_references; Type: TABLE DATA; Schema: public; Owner: - -- COPY public.upload_references (id, upload_id, target_type, target_id, created_at, updated_at) FROM stdin; 45698 760 Post 667 2023-05-05 04:11:35.947138 2023-05-05 04:11:35.947156 42396 6674 Post 3903 2023-05-05 01:59:37.447183 2023-05-05 01:59:37.447202 45699 761 Post 667 2023-05-05 04:11:35.947163 2023-05-05 04:11:35.947167 \. 这样的格式。 这样的格式只能使用 psql 来进行导入。 注意到上面有一个 COPY FROM stdin; 这个是 psql 的专用导入格式。 导入的命令为： psql -h 127.0.0.1 -p 5433 -U username -W -d database name < dump.sql 我们在导入的命令中加入了不少的参数。 有关 psql 的参数列表，请参考文章：PostgreSQL: Documentation: 15: psql. 上面的参数中： -h 服务器地址 -p 数据库服务器运行端口 -U 登录用户名 -W 登录密码 -d 数据库名 当导入开始后，在控制台上，会出现导入结果。 数据提示 在导入的数据库，中我们发现 PostgreSQL 使用的 COPY Stdin。 在数据的默认有一个数据终止符 \.。 这个数据终止符是不能丢的。 https://www.isharkfly.com/t/postgresql-psql-sql/14720
Discourse 提供了较为完善的日志查看方式。 用得最多的可能就是 Logster 的基于 Web 的 UI 了。 Logster Discourse 的错误日志面板用的是 logster，采集的是 Rails/Rack 的日志，正常应该用 Rails::Logger 但是 discourse 做了封装。 正常的访问地址为你的域名后面添加 logs。 例如，可以访问域名后面添加 logs 的地址。 但需要注意的是，你需要登录系统，具有系统管理员的访问权限才可以。 否则将会出现页面没有找到的错。 系统日志 和所有系统一样，Discourse 使用了 nginx 为 Web 服务器。 这个日志不会显示在 logster 上面的。 你需要进入你的服务器后才能看到。 Discourse 做了系统的优化，把系统使用的日志卷给映射出来了，你并不需要进入容器才能看到日志。 举个例子，我们希望看见 nginx 的 access 访问日志。 那么在你的服务器上可以直接访问： /var/discourse/shared/standalone/log/var-log/nginx 这个地址就可以了。 所有容器中的日志，也可以通过上面的路径查看到，你并不需要进入 Discourse 的容器内。 https://www.isharkfly.com/t/discourse/14715