Library not loaded: @rpath/libcurl.4.dylib

by

当你在 macOS 上遇到“Library not loaded: @rpath/libcurl.4.dylib”的错误时，这通常意味着你的应用程序在运行时找不到指定的动态链接库（DLL）文件。这种情况通常发生在以下几种情况：

解决方案

  1. 确保库文件存在：确保 libcurl.4.dylib 文件存在于你的应用程序的 @rpath 目录下。你可以使用 install_name_tool 来查看和修改库文件的路径。
  2. 设置正确的运行路径：使用 install_name_tool 来修改库文件的安装名称（install name）。例如，如果你的应用程序位于 /Applications/MyApp.app，而 libcurl.4.dylib 位于该应用的 Contents/Frameworks 目录下，你可以使用以下命令来设置正确的运行路径：install_name_tool -change @rpath/libcurl.4.dylib @executable_path/../Frameworks/libcurl.4.dylib /Applications/MyApp.app/Contents/MacOS/MyApp
  3. 或者，如果你使用的是 Xcode，可以在项目的 Build Phases 中添加一个 Run Script Phase，在其中加入上述命令。
  4. 检查构建配置：确保你的项目配置正确设置了运行时搜索路径（Runpath Search Paths）。在 Xcode 中，你可以在 Target 的 Build Settings 中查找 Runpath Search Paths，并添加包含 libcurl.4.dylib 的目录。例如：
    • 在 Xcode 的 Build Settings 中，找到 Runpath Search Paths 并添加 @executable_path/../Frameworks。
  5. 使用 lipo 工具验证架构：确保 libcurl.4.dylib 支持你的应用程序架构（如 arm64, x86_64 等）。你可以使用 lipo 工具来检查和修改库文件的架构：lipo -info /path/to/libcurl.4.dylib如果库文件的架构不正确，你可能需要重新编译或获取正确架构的库文件。
  6. 清理和重建项目：有时候，简单的清理和重建项目可以解决路径或配置问题。在 Xcode 中，你可以选择 Product > Clean Build Folder，然后重新构建项目。

通过上述步骤，你应该能够解决 “Library not loaded: @rpath/libcurl.4.dylib” 的错误。如果问题仍然存在，检查是否有其他依赖问题或配置错误，并确保所有依赖库都已正确安装和配置。

getExternalCacheDir与getCacheDir的区别

by

getCacheDir
getCacheDir()其对应着应用程序内的内部缓存，用来存储临时数据。因此在系统空间较少时有可能会被自动清除。存放路径一般是/data/data/<应用包名>/cache目录。

getExternalCacheDir
getExternalCacheDir()对应着应用程序内的外部缓存，同样是用来存储临时数据的。但是其由于脱离了应用管理，因此并不会在空间少时被自动清除。存放路径一般是/storage/sdcard/Android/data/<应用包名>/cache目录。

应用卸载
当用户卸载当前应用程序时，以上两个方法里的内容都会随着应用卸载所清除。若有想要一直保存的内容，可以调用getExternalStorageDirectory目录下（抑或其他sd卡下的目录）进行保存。

当然，如果想要保存文件数据（长时间保存），上面对应着getFilesDir()和getExternalFilesDir()，类比即可。

笔记
可以看到，当有External（外存）时，数据都是缓存在sd卡中的（若存在）；否则则是内部缓存（可管理）。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.csdn.net/CarsonWoo/article/details/89142756

android变量被系统回收,Android使用static定义全局变量被系统回收的问题

by

ppConstants.java

public static  String AppPay = “AppPay”;

public static  String AppPay_AccountPay = “/AccountPay”;

public static  String AppPay_TencentPay = “/TencentPay”;

public static  String AppPay_AllinPay = “/AllinPay”;

public static  String AppPay_VCardPay = “/VCardPay”;

public static  String AppPay_GetPayHistory = “/GetPayHistoryByUserId”;

public static  String AppPay_OrderConfirm = “/OrderConfirm”;

大家在开发Android应用的时候，应该会有沿用java的习惯，用static定义一些全局的变量。可是Android对进程和内存管理不同于PC的核心——如果资源足够，Android不会杀掉任何进程，另一个意思就是进程随时可能会被杀掉。而Android会在资源够的时候，重启被杀掉的进程。也就是说静态变量的值，如果不做处理，是不可靠的，可以说内存中的一切都不可靠。

网上很多文章说用Application来保存一些全局变量，这个方法经过我尝试之后，发现还是会被清空。怎么办呢？

当我快绝望的时候，忽然想起一个方法onSaveInstanceState()!我们可以覆写Activity的onSaveInstanceState()方法，保存当前页面的一些数据，在进程被摧毁之后，重新回到页面的时候，在onCreate(Bundle savedInstanceState)中的savedInstanceState取到保存的数据。本以为这样就可以解决问题了，但是想想之后，发现不可能每个页面都去保存一大堆变量。

最后我想到java的反射机制，可以为成员变量赋值，因为当应用的进程被系统摧毁之后，再回到应用，Application会重启，执行onCreate()方法，所以我就在onCreate()里调用

public void initAppData(){

try {

Class> clazz = AppConstants.class;

//获取这个类所有的成员变量

Field[] fields = clazz.getDeclaredFields();

for(Field field : fields) {

Object appConstants;

//得到一个实例

appConstants = clazz.newInstance();

field.set(appConstants, field.get(field.getName()));

}

}catch (InstantiationException e) {

e.printStackTrace();

}catch (IllegalArgumentException e) {

e.printStackTrace();

} catch (IllegalAccessException e) {

e.printStackTrace();

}

}

Application重启之后，再进行数据的初始化。

link: https://blog.csdn.net/weixin_33443972/article/details/117617251

在JNI中使用SetSystemProperty

by

文章目录

在 Java Native Interface (JNI) 中，SetSystemProperty 并不是一个直接可用的函数或方法。通常，你会通过 JNI 调用 Java 的系统属性相关方法来设置系统属性。

如何在 JNI 中设置系统属性

  1. 获取 java.lang.System 类：你需要首先获取 System 类的引用。
  2. 获取 setProperty 方法：然后获取这个类中 setProperty 方法的引用。
  3. 调用方法：通过 JNI 调用这个方法来设置属性。

示例代码

以下是一个简单的示例，展示了如何在 JNI 中设置一个系统属性：

#include <jni.h>
#include <stdio.h>

JNIEXPORT void JNICALL Java_YourClass_setProperty(JNIEnv *env, jobject obj) {
    jclass systemClass = (*env)->FindClass(env, "java/lang/System");
    if (systemClass == NULL) {
        return; // 处理错误
    }

    jmethodID setPropertyMethod = (*env)->GetStaticMethodID(env, systemClass, "setProperty", "(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;");
    if (setPropertyMethod == NULL) {
        return; // 处理错误
    }

    jstring key = (*env)->NewStringUTF(env, "myProperty");
    jstring value = (*env)->NewStringUTF(env, "myValue");

    (*env)->CallStaticObjectMethod(env, systemClass, setPropertyMethod, key, value);

    // 清理局部引用
    (*env)->DeleteLocalRef(env, key);
    (*env)->DeleteLocalRef(env, value);
    (*env)->DeleteLocalRef(env, systemClass);
}

使用步骤

  1. 编译并生成共享库：确保你的 JNI 代码编译正确，并生成相应的共享库（如 .dll、.so 文件）。
  2. 在 Java 中加载本地库：使用 System.loadLibrary("your_library_name") 来加载本地库。
  3. 调用 JNI 方法：从 Java 代码中调用 setProperty 方法。

注意事项

  • 设置的系统属性在 JVM 运行期间有效，但不会影响外部环境。
  • 确保在多线程环境下小心使用，以避免潜在的数据竞争问题。

解决：RPM软件包: 错误：无法从 /var/lib/rpm 打开软件包数据库

by

错误原因

可能由于强制结束了yum操作而导致rpm数据库被损坏了！不一定是你手动结束，也可能是因为网络原因

解决方案

删除已损坏的 __db 文件

进入rpm目录命令：
cd /var/lib/rpm
#删除 __db 文件命令：两种方式任选一种
#方式一：
rm /var/lib/rpm/__**
#方式二：
rm -i __db.*
重建rpm数据库
#重新构建rpm数据库命令：
rpm –rebuilddb

MySQL MGR集群原理及实践

by

一、MGR简介

MGR全称MySQL Group Replication（Mysql组复制），是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案。MGR提供了高可用、高扩展、高可靠的MySQL集群服务。在MGR出现之前，用户常见的MySQL高可用方式，无论怎么变化架构，本质就是Master-Slave架构。MySQL 5.7版本开始支持无损半同步复制（lossless semi-syncreplication），从而进一步提示数据复制的强一致性。

MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供。MGR基于分布式paxos协议，实现组复制，保证数据一致性。内置故障检测和自动选主功能，只要不是集群中的大多数节点都宕机，就可以继续正常工作。提供单主模式与多主模式，多主模式支持多点写入。

二、MGR原理

组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的Server集群。复制组由多个Server成员组成，如下图的Master1、Master2、Master3，所有成员独立完成各自的事务。

当客户端发起一个更新事务时，该事务先在本地执行，执行完成之后就要发起对事务的提交操作。在还没有真正提交之前，需要将产生的复制写集广播出去，复制到其它成员。如果冲突检测成功，组内决定该事务可以提交，其它成员可以应用，否则就回滚。

最终，所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改，保证组内数据强一致性。

三、MGR特点

高一致性。基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；

高容错性。只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；

高扩展性。节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；

高灵活性。有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。

四、使用限制

（1） 仅支持innodb引擎

​为什么需要使用innodb引擎呢？在MySQL Group Replication中，事务以乐观形式执行，但是在提交时检查冲突，如果存在冲突，则会在某些实例上回滚事务，保持各个实例的数据一致性，那么，这就需要使用到事务存储引擎，同事Innodb提供一些额外的功能，可以更好的管理和处理冲突，所以建议 业务使用表格使用inndb存储引擎，类似于系统表格mysql.user使用MyISAM引擎的表格，因为极少修改及添加，极少出现冲突情况。

（2）主键

​每个需要复制的表格都必须定义一个显式主键，注意跟隐式主键区分（使用Innodb引擎的表格，如果没有指定主键，默认选择第一个非空的唯一索引作为主键，如果没有，则自动创建一个6个字节的rowid隐式主键）。这个主键能在冲突发生时启动极其重要的作用，同时，能够有效提高relay log的执行效率。

（3）隔离级别

​官网建议使用READ COMMITTED级别，除非应用程序依赖于REPLEATABLE

READ，RC模式下没有GAP LOCK，比较好支持Innodb本身的冲突检测机制何组复制的内部分布式检测机制一起协同工作。不支持SERIALIZABLE隔离级别。

（4）外键

​不建议使用级联外键，如果旧库本身有外键，业务上无法去除并且使用的是多主模式，那么，请配置group_replication_enforce_update_everywhere_check ，强制检查每个组成员的级联检查，避免多主模式下执行级联操作造成的检测不到的冲突。

五、参数规范

因前期创建实例大多采取默认配置 导致开发，测试，生产等环境间数据库参数不同 对程序运行有一定的影响。 以后创建实例将会参数规范化 对已有的实例后续也会慢慢修正。

下面简单解释下几个改动的参数

sql_mode 去除了ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES,NO_ZERO_IN_DATE, NO_ZERO_DATE等限制 采取了较为宽松的模式

lower_case_table_names 统一设置为1 即不区分大小写 有些实例还没更改 大家建表建库的时候不要大写

character-set-server 统一设置为utf8 不要用latin1字符集

wait_timeout和interactive_timeout参数控制空闲连接的时长 当连接空闲时间超过此参数则会被断开 以后会统一设置为1800s即30分钟

transaction_isolation 事务隔离级别 MySQL官方默认是可重复读（repeatable-read）目前单实例及主从架构的mysql采用了此级别，MGR集群将采取读已提交（read-committed）级别。Oracle默认是读已提交 。

六、两地三中心应用

随着互联网业务快速发展，多IDC的业务支撑能力和要求也逐步提升，行业内的“两地三中心”方案较为流行。其中两地是指同城、异地；三中心是指生产中心、同城容灾中心、异地容灾中心。

两地三中心方案中，基于设定的短期目标可以明确同城双活和异地容灾的方案组合。设计重点为同城双活，即在同城的数据中心之间，一般通过高速光纤相连，在网络带宽有保障的前提下，网络延迟一般在可接受范围内，两个机房之间可以认为在同一个局域网内。

在设计上可以和应用层结合起来，有两种部署模式：分为应用层双活和数据库双活，应用层双活和数据库单活。

（1）MGR集群多活架构

基于MGR的多活特性，数据的写入可以在多个节点之间进行复制，实现数据强一致性需求，并且在节点间通信出现延迟的情况下，会自动实现服务降级。对于此类方案，我们可以采用同机房多写，同城异机房只读的方案。

（2）双主模式的多活

两个节点均可以写入数据，可以实现跨机房的数据复制，延迟较低，在业务层需要做隔离，在故障发生时能够快速切换到同机房的Slave节点。此方案对于两个IDC机房的场景中较为实用，但是机房多活的场景不适合。

（3）业务交叉的双活方案

此种方案是双活技术的变通实现，即存在两类业务A和B,数据存储在database级别（schema层级），分别在不通的IDC节点完成数据写入，比如业务A在IDC1完成写入，业务B在IDC2完成写入，两个节点之间存在跨机房的复制节点，在出现问题时，能够通过域名的方式切换到指定的IDC节点。此种方案对于业务的依赖性较高，不适合机房多活的场景。

作者：架构设计思维

Link: https://www.jianshu.com/p/b9831f15e10c

更新jar包里的配置文件

by

文章目录

方法一，更新jar包文件

最先想到的办法是用命令把jar包解压jar -xvf xxx.jar 修改完毕后重新打包 jar cf xxx.jar * ，本以为是大功告成，执行java -jar xxx.jar 报错

no main manifest attribute,in xxx.jar

经了解需要在MANIFEST.MF文件添加main方法的类。用maven打包的话这些都自动配置了。 对比两次生成MANIFEST.MF文件里边确实少了不少内容项，根据报错内容主要的main方法的类没有指定

Main-Class: org.springframework.boot.loader.JarLauncher
Start-Class: xxxApp

用jar重新打包的方法肯定是不行了，肯定还有需要注意的细节。又一想我只是要修改配置文件，替换掉jar包里的配置文件就可以了。查了下jar的文档。果然有更新方法：

jar uf xxx.jar BOOT-INF/classes/application-dev.yml

替换之，启动jar,顺顺利利的启动了。

方法二，jar重新打包

后来对于最先想到的方法又在网上查了下，也有对应的解决办法,但是会有两个问题要处理

  1. 阻止jar打包时重新生成清单列表，  -M 不配置配置清单，这样还可以使用maven生成的配置清单也就是MANIFEST.MF
jar -cfM xxx.jar *
  1. jar打包时不进行压缩 -0
jar -cfM0 xxx *

压缩的话会有错误，如下：(已被压缩，嵌套的jar文件无需被压缩)

Unable to open nested entry 'BOOT-INF/lib/cache-api-0.4.jar'.
It has been compressed and nested jar files must be stored without compression.

最终命令：jar -cfM0 xxx.jar *

Link: https://www.cnblogs.com/dayou123123/p/6845432.html

npm/yarn设置淘宝源

by

npm淘宝源

npm config set registry=https://registry.npm.taobao.org
npm config set sass_binary_site=https://npm.taobao.org/mirrors/node-sass/
npm config set phantomjs_cdnurl=https://npm.taobao.org/mirrors/phantomjs/
npm config set electron_mirror=https://npm.taobao.org/mirrors/electron/

yarn淘宝源

yarn config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/
yarn config set phantomjs_cdnurl https://npm.taobao.org/mirrors/phantomjs/
yarn config set electron_mirror https://npm.taobao.org/mirrors/electron/

link: https://www.cnblogs.com/mldonkey/p/13387119.html