250929-Java-Semaphore信号量多线程并发控制

多线程并发信号量控制逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
/**/
private static final ConcurrentHashMap<String, Long> LOCK_DTO_MAP = new ConcurrentHashMap<>();

private static final ConcurrentHashMap<String, Semaphore> SEMAPHORE_MAP =
    new ConcurrentHashMap<>();

private static final long TIMEOUT_DURATION = 60_000; // 60 seconds

public static boolean lock(String key) {
  Semaphore semaphore = SEMAPHORE_MAP.computeIfAbsent(key, k -> new Semaphore(1, true));
  boolean acquired = false;

  try {
    // 1. 拿到许可证
    acquired = semaphore.tryAcquire(1, TimeUnit.SECONDS);
    Preconditions.checkState(acquired, "获取锁超时: " + key);

    // 2. 现在互斥了，再操作被保护资源
    Long old = LOCK_DTO_MAP.putIfAbsent(key, System.currentTimeMillis());
    Preconditions.checkState(old == null, "Lock already held by this thread for key: " + key);

    return true;
  } catch (Exception ignored) {
  } finally {
    /* 4. 关键：只有真正拿到过许可的线程才需要“善后” */
    if (acquired) {
      /* 4.1 判断是否超时，超时就当“没发生过”直接删记录 */
      try {
        long holdTime = System.currentTimeMillis() - LOCK_DTO_MAP.get(key);
        if (holdTime > TIMEOUT_DURATION) {
          LOCK_DTO_MAP.remove(key); // 删记录" 超时，记录+许可证已清理"
        }
      } finally {
        semaphore.release(); // 还许可证
      }
    }
  }
  return false;
}

/** 清空StripedLockUtils的所有数据 */
public static void clearAppRestart() {
  for (String key : LOCK_DTO_MAP.keySet()) {
    StreamUtils.silentException(
        () -> {
          unlock(key);
          SEMAPHORE_MAP.remove(key);
        });
  }
}

public static void unlock(String key) {
  StreamUtils.silentException(() -> LOCK_DTO_MAP.remove(key));
}

Kubernetes

可根据命令来查看对应的版本
kubectl version 、
kubeadm version 、
kubelet –version、

Kubeadm 是一个提供了 kubeadm init 和 kubeadm join 的工具， 作为创建 Kubernetes 集群的 “快捷途径” 的最佳实践；
Kubelet 是 Kubernetes 集群中的一种重要的核心组件，运行在每一个节点上，负责管理和执行在节点上运行的容器；
Kubectl 是一个用于与运行在 Kubernetes 集群上的容器化应用进行交互和管理的命令行工具。
详细的组件工具介绍可参考 kubernetes 的官方文档

安装kubeadm，kubelet和kubectl

1
2
sudo yum install -y kubelet-1.18.0 kubeadm-1.18.0 kubectl-1.18.0
systemctl enable kubelet

以 Ubuntu 为例，可以通过以下命令安装这些组件：

1
2
3
4
5
6
7
8
sudo apt-get update
sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

TIPS：K8S集群还未拉起，故这里的kubelet是无法启动的，等master初始化时会自动拉起。

安装 Kubernetes 组件

在所有服务器上安装 Kubernetes 的三个主要组件：kubelet、kubeadm 和 kubectl。
kubelet 是在集群中每个节点上运行的主要节点代理，它确保容器都运行在 Pod 中。
kubeadm 是一个工具，用于安装、初始化和管理 Kubernetes 集群。
kubectl 是 Kubernetes 命令行工具，用于与 Kubernetes 集群进行交互。

安装完成后，
可以通过命令 kubeadm version、kubectl version 和 kubelet –version
来验证这些组件是否安装成功。

验证集群状态
在主节点上，通过命令 kubectl get nodes 来查看集群中的节点状态。
所有节点的状态应该都是 Ready，表示它们已经成功加入集群并且可以正常工作。
你还可以通过命令 kubectl get pods –all-namespaces 来查看集群中所有 Pod 的状态，
确保控制平面组件和 Pod 网络插件的 Pod 都在正常运行。

250927-RPM查看安装软件和卸载软件(rpm -qa | grep mongodb-org)

  1. 确认已安装的 MongoDB 家族版本

    1
    rpm -qa | grep mongodb-org

典型输出：

1
2
3
4
5
mongodb-org-server-8.2.0-1.el8.x86_64
mongodb-org-shell-8.2.0-1.el8.x86_64
mongodb-org-tools-8.2.0-1.el8.x86_64
mongodb-org-mongos-8.2.0-1.el8.x86_64
mongodb-org-database-tools-extra-8.2.0-1.el8.x86_64

  1. 卸载

    1
    rpm -e mongodb-org-server-8.2.0-1.el8.x86_64

输出

1
2
Removed /etc/systemd/system/multi-user.target.wants/mongod.service.
warning: file /run/mongodb: remove failed: No such file or directory

250913-Shell工具Shell-MobaXterm重置主密码工具

mobaxterm密码忘记，如何重置密码？

解决方法： 使用MobaXterm主密码重置工具ResetMasterPassword，一键去除打开软件主密码。

官网 MobaXterm free Xserver and tabbed SSH client for Windows (mobatek.net)

https://mobaxterm.mobatek.net/

软件去掉密码 MobaXterm Xserver and tabbed SSH client - resetmasterpassword (mobatek.net)

ResetMasterPassword.zip

https://mobaxterm.mobatek.net/resetmasterpassword.html

250902-ubuntu20.04分辨率-只有一个800x600的分辨率怎么升级

在Ubuntu 20.04中，如果遇到分辨率只有800x600的情况，可以尝试以下方法来升级或调整分辨率：

更新软件

1
2
sudo apt update
sudo apt upgrade

配置GRUB

可以在/etc/default/grub文件中找到注释掉的GRUB_GFXMODE行，取消注释并设置为你的目标分辨率，例如GRUB_GFXMODE=1920x1080
，然后更新GRUB配置并重启

1
GRUB_GFXMODE=1920x1080

250901-MySQLImport导入数据-以确保字符集的一致性--default-character-set=utf8

–default-character-set=utf8

遇到 “ERROR at line 13404: Unknown command ‘’’” 错误时，这通常是由于字符集问题导致的。为了解决在 MySQL
导入数据时的问题，可以尝试以下几种方法：

  1. 指定字符集：在导入命令中添加 --default-character-set=utf8 参数，以确保字符集的一致性。例如：

    1
    mysql -u root -h 127.0.0.1 -P 33067 --default-character-set=utf8 mujitokyo_dev<mujitokyo_dev.sql

这样可以避免因字符集不匹配导致的数据导入失败

。

  1. 检查文件编码：确保 SQL 文件的编码格式与 MySQL 服务器的编码格式一致。可以使用文本编辑器或命令行工具（如 ）来转换文件编码。

  2. 使用特定编码导出：在导出数据库时，就使用特定编码的形式导出。例如，如果需要导入的数据库环境编码是utf8，那么在导出时就使用utf8格式。

  3. 调整命令行客户端编码：在命令行客户端连接服务器时指定编码，例如：

    1
    mysql -uroot -h192.168.1.101 -p --default-character-set=utf8

这可以避免前面遇到的错误

。

  1. 修改 max_allowed_packet 设置：如果导入的 SQL 文件较大，可能需要调整 MySQL 的 max_allowed_packet 设置，以允许更大的数据包传输

250901-MySQL--skip-grant-tables跳过权限表-处理数据库异常恢复数据

你可以将 --skip-grant-tables 选项添加到 MySQL 的配置文件中，以便在每次启动时自动应用此设置。然而，需要注意的是，
--skip-grant-tables 选项会跳过权限表的加载，这意味着所有用户都可以无需密码登录到 MySQL
服务器，这会带来重大的安全风险。因此，通常只在进行特定维护任务时临时使用此选项。

将 --skip-grant-tables 添加到配置文件

  1. 找到 MySQL 配置文件： MySQL 的配置文件通常名为 my.cnf 或 my.ini，位于 /etc/mysql/、/etc/mysql/mysql.conf.d/
    或 MySQL 安装目录下。

  2. 编辑配置文件： 打开配置文件，找到 [mysqld] 部分，并添加 --skip-grant-tables 选项。例如：

    1
    2
    [mysqld]
    skip-grant-tables

  3. 保存并关闭文件。

  4. 重启 MySQL 服务： 重启 MySQL 服务以应用更改：

    1
    sudo systemctl restart mysql

使用 --skip-grant-tables 的注意事项

  • 安全性：由于 --skip-grant-tables 会跳过权限检查，任何用户都可以无需密码登录到 MySQL
    服务器。因此，在使用此选项时，必须确保数据库服务器不对外部网络开放，或者在防火墙中严格限制访问权限。
  • 临时使用：通常只在需要修复权限表或进行其他需要跳过权限检查的维护任务时临时使用 --skip-grant-tables
    。完成这些任务后，应立即从配置文件中移除此选项，并重启 MySQL 服务。
  • 备份：在修改配置文件或进行任何可能影响数据库安全性的操作之前，确保备份所有重要数据。

从配置文件中移除 --skip-grant-tables

完成维护任务后，应立即从配置文件中移除 --skip-grant-tables 选项，并重启 MySQL 服务以恢复正常的权限检查：

250901-MySQL-LogFile-ib_logfile启动异常处理

异常信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2025-09-01T01:38:07.723468Z 0 [ERROR] InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint 1108276937 and the end 1108281882.
2025-09-01T01:38:07.723499Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2025-09-01T01:38:08.332206Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2025-09-01T01:38:08.332263Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2025-09-01T01:38:08.332280Z 0 [ERROR] Failed to initialize builtin plugins.
2025-09-01T01:38:08.332294Z 0 [ERROR] Aborting

2025-09-01T01:38:08.332312Z 0 [Note] Binlog end
2025-09-01T01:38:08.332392Z 0 [Note] Shutting down plugin 'CSV'
2025-09-01T01:38:08.334119Z 0 [Note] mysqld: Shutdown complete


2025-09-01T03:20:31.722426Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-09-01T03:20:31.722543Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=635] log sequence number 1041821149 is in the future! Current system log sequence number 1040642590.
2025-09-01T03:20:31.722583Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-09-01T03:20:31.722683Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=1371] log sequence number 1040709155 is in the future! Current system log sequence number 1040642590.

从你提供的日志来看，
MySQL 在启动时遇到了与 InnoDB 存储引擎相关的问题，导致无法正常启动。
以下是日志中显示的几个关键问题及其可能的原因：

1. InnoDB 忽略重做日志

1
2
3
2025-09-01T01:38:07.723468Z 0 [ERROR] 
              InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT 
              between the checkpoint 1108276937 and the end 1108281882.
  • 问题描述：InnoDB 在启动时检查重做日志（redo log），发现缺少 MLOG_CHECKPOINT，导致无法正确恢复数据。
  • 可能原因：
    • 数据库在上次关闭时没有正常关闭，导致重做日志不完整。
    • 数据文件（如 ibdata1 或 ib_logfile*）可能被损坏或丢失。

2. 可以尝试删除的文件

**ib_logfile\***：这些是 InnoDB 的重做日志文件，用于恢复操作

在某些情况下，可以尝试删除一些临时文件或日志文件，但需要谨慎操作：

  • **ib_logfile\***：如果这些文件损坏，可以尝试删除它们，然后重新启动 MySQL。MySQL 会自动重新创建这些文件。但请注意，这可能会导致一些未提交的事务丢失。
  • **\*.err**：这是 MySQL 的错误日志文件，删除它不会影响数据库的运行，但建议先备份，以便后续查看错误信息。